Carl Love

Carl Love

24673 Reputation

25 Badges

10 years, 58 days
Natick, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@jediknight Let be the gain function, which you want to maximize with respect to wx. Let G'(wx) be its derivative. You are doing this, essentially:

  1. Let wx_max be the unique positive solution to G'(wx) = 0.
  2. Let Top_of_Q be G(wx_max).
  3. Let wx_max be the unique positive solution to G(wx) = Top_of_Q.

Step 3 is redundant; wx_max is already known from step 1. The equation G'(wx) = 0 is easier to solve numerically than G(wx) = Top_of_Q, and fsolve will refuse to solve an equation if it can't guarantee the accuracy of the solution to 10 decimal places.

The code that I just gave you doesn't do step 3.

@mmcdara Thanks. The algcurves package I think predates my first Maple version, Maple V r4. Some of the highlighted points are where the tangent is horizontal or vertical; I don't know what the others are. The command plot_real_curve only works for polynomials in two variables, but I like it because it figures out the ranges for the variables automatically.

@delvin Your 1st line implicitly defines U as a function of xi. So, the next line should be

eq:= 6*c^2*U + 9*c*U^2 + 3*U^3 - diff(U, xi$2);

@jediknight I get this:

restart:
GainQ:= 8*wx^2*(m-1)/(Pi^2*sqrt((m*wx^2-1)^2+Q^2*wx^2*(wx^2-1)^2*(m-1)^2));
params:= [m=6];
Qs:= [0.20, 0.30, 0.40, 0.70, 1.0, 6.0]:
a:= subs(params, GainQ);
da:= numer(diff(a, wx));
for q in Qs do
    x:= fsolve(subs(Q= q, da), wx= 0.01..infinity);
    Top:= subs(wx= x, Q= q, a);
    printf(`Q = %a, wx_max= %a, Top = %a\n`, q, x, Top)
od:  

Q = .20, wx_max= .4257659439, Top = 2.043988894
Q = .30, wx_max= .4507684910, Top = 1.415858396
Q = .40, wx_max= .4927877155, Top = 1.124695001
Q = .70, wx_max= .7476605392, Top = .8641647894
Q = 1.0, wx_max= .8878848311, Top = .8306147086
Q = 6.0, wx_max= .9972137076, Top = .8110221752

Are any of these unexpected? If so, why?

What is your intended purpose of this line of code?

v := t->vs(t); l/~nvs;

The first part, v:= t->vs(t), is semantically equivalent to v:= vs; thus it serves no practical purpose. The second part, l/~nvs, has no practical effect at all because it doesn't change the value of any variable.

@mmcdara I think that convert(..., unit_free) is the way to go. If you encounter some situation where that doesn't work (I don't have any reason to suspect that such a situation exists, but Maple often surprises), then I think a reasonable alternative is

eval(..., Units:-Unit= 1)

@tomleslie I did see the bug that you described earlier today when I tried the same thing, but now it's gone. Try doing restart. If that doesn't fix it, try using 1-D input. (I'm quite curious which of those two fixes it.) Anyway, using my code from above with the only change being semilogplot instead of loglogplot, I get

@acer Is explicitly combining addends necessary for the OP's Maple 2015? It doesn't seem necessary in Maple 2022 (if accepting the SI unit).

b:= 7*Unit(mm)+3*Unit(m);
convert(b, unit_free);
 

@mmcdara Good Answer; voted up.

I guess that you didn't try searching "trace" in the help. The command to trace is simply trace(...procedure name(s)...). Thus IF1 can be reduced to

IF1:= (__w1, __w2, __x1, __x2, __x3)->
    evalf(
        Int(
            eval(MM, [w1= __w1, w2= __w2, x1= __x1, x2= __x2, x3= __x3])
           , [b2= 1..2, b3= 1..2]
           , method= _d01ajc
           , epsilon= 0.001
         )
    )
:

And do

trace(IF1):

before calling NLPSolve.

@The function I think that the breadth of my Reply has been misinterpreted. I was only objecting to this statement by @vv , which I thought was too simplistic:

  • For a) it's enough to compute simplify(A . B), obtaining the unit matrix, without any assumption on p.

In his followup Reply to my objection, he changed that to

  • A and B having polynomial entries, A.B = Id ==> A invertible, that's all. [Emphasis added.]

That modified statement I no longer think too simplistic. Both A and B having polynomial entries (i.e., no variables in denominators) is sufficient to guarantee that A is invertible for all p. (*1)  Regarding the determinant-based solution: If A has polynomial entries, and Determinant(A) is a nonzero constant, then A is invertible for all p. (*2)

Regarding the two proposed counterexamples, A1:= <<p>> and A2:= <p, 0; 0, 1/p>: The symbolic inverse of A1 is <<1/p>>, which is not a polynomial matrix. For A2Determinant(A2) = 1, a nonzero constant, but A2 is not a polynomial matrix. So neither of these are counterexamples to (*1) or (*2). I had proposed A1 as a counterexample to vv's initial statement, which didn't mention polynomials.

@Rouben Rostamian  The OP's plaintext transcription contains all the information needed to Answer the Question, if it can be answered at all. Yes, the so-called ODE is not an ODE in the usual sense, but nonetheless dsolve will give a symbolic solution to it (actually 3 solutions). The Question is whether any or all of those solutions are correct. 

I've tried several things, and at this point I'm leaning towards "they're not correct", but that's just a guess.

@vv The problem is simple, but it's not that simple. Suppose A = <<p>>. Both Maple and I would claim that A is non-singular with A^(-1) = <<1/p>>. (There is a formal context to make this entirely valid that I can elaborate upon if you want.) But the problem at hand asks us for the isolated singularities (without putting it in those words). For A = <<p>>p=0 is one of those isolated singularities. Maple's assumptions don't handle isolated singularities.

@JAMET Change this line:

seq(plot([[1/2*cos(Pi/6+i*1/5), 1/2*sin(Pi/6+i*1/5)],[0,0]],i=1..10),color=black)

to

seq(plot([[1/2*cos(Pi/6+i*1/5), 1/2*sin(Pi/6+i*1/5)],[0,0]], color= black),i=1..10)

The only difference is switching the position of i= 1..10 with color= black.

@nm Why not just redefine solve as a local procedure? Then the only change that you need to make is adding a half line of code. Example:

restart:
Program:= proc(expr, A)
local eq, solve:= eq-> :-solve(simplify(eq), _rest);
    eq:= expr;
    (solve(eq, _rest) assuming `if`(A::{list,set}, A[], A))
end proc
: 
Program(sqrt(exp(y))=tanh(x), [y::real, x>0], y);
                         2 ln(tanh(x))

Or you could make the local redefinition simply solve:= PDEtools:-Solve;

@nm The reason that assuming works differently from assume here is that the assume is in effect when sqrt(exp(y)) is entered, which causes that to immediately simplify to exp(y/2) under the y::real assumption. The code that causes this to happen is lines 83-85 of sqrt:-ModuleApply.

Without any assumptions in effect at the time that the sqrt is entered, it returns exp(y)^(1/2)This expression does not have an unevaluated sqrt. Thus, there's no way to go back to lines 83-85 after the assuming takes effect.

4 5 6 7 8 9 10 Last Page 6 of 641