Alejandro Jakubi

MaplePrimes Activity


These are answers submitted by Alejandro Jakubi

Efficiency, a priori, as dsolve may try some other methods before:

> infolevel[dsolve]:=3:
> ode := diff(z(t),t) + p(t)*z(t) = q(t)*z(t)^2;
                          /d      \                        2
                   ode := |-- z(t)| + p(t) z(t) = q(t) z(t)
                          \dt     /
> 
> DEtools[bernoullisol]( ode, z(t) );
trying Bernoulli
<- Bernoulli successful
                                        /
                                       |
                                  exp( |  -p(t) dt)
                                       |
                                      /
                 {z(t) = ------------------------------------}
                           /        /
                          |        |
                          |  -exp( |  -p(t) dt) q(t) dt + _C1
                          |        |
                         /        /
> 
> dsolve( ode, z(t) );
Methods for first order ODEs:
--- Trying classification methods ---
trying a quadrature
trying 1st order linear
trying Bernoulli
<- Bernoulli successful
                                        /
                                       |
                                  exp( |  -p(t) dt)
                                       |
                                      /
                  z(t) = ------------------------------------
                           /        /
                          |        |
                          |  -exp( |  -p(t) dt) q(t) dt + _C1
                          |        |
                         /        /

This is a well known class of bugs that affects many routines. This toy example shows the point:

if 0 < 183.3333333*Pi then
1 else 0;
end if;

Error, cannot determine if this expression is true or false: 0 < 183.3333333*Pi

In the boolean evaluation of this expression Pi is a name, not a number. So, somewhere in the code it has to be numerically evaluated, like:

evalf(Pi);
                          3.141592654

for the comparison to be made, but this step was missed. It should be easy to fix. Posting the complete session could help to identify the location of this bug and find a workaround.

I find useful the table of Characters Ordered by Unicode. You may find, e.g. "lowast" and its unicode value in hexadecimal 2217. So, either the name, or the decimal value 8727 work in the Standard GUI:

> `&lowast;`;
                                    ∗
> `&#8727;`;
                                    ∗

For further investigation of this bug, I have used a variation of Preben's expression, and made a single assumption on k, which seems the critical one:

> assume(k > 0); 
> V:=(-1/2*(-((k*mu)^(1/4)/a^(1/2))^(1/2)*(k*mu)^(1/2)+((k*mu)^(1/4)/a^(1/2))^(1/2)*
> k*mu)/mu+1/2*k*((k*mu)^(1/4)/a^(1/2))^(1/2))/(k/mu)^(1/2)/((k*mu)^(1/4)/a^(1/2)
> )^(1/2);

Under this conditions, the bug seems located at the routine simplify/sqrt/fraction or close to it. Its somewhat long trace shows that it receives a slight variation of the original expression, and returns a wrong result:

> trace(`simplify/sqrt/fraction`):
> simplify(V);
{--> enter simplify/sqrt/fraction, args = ((1/2*(k^(1/4)*mu^(1/4)/a^(1/2))^(1/2
)*(k*mu)^(1/2)-1/2*(k^(1/4)*mu^(1/4)/a^(1/2))^(1/2)*k*mu)/mu+1/2*k*(k^(1/4)*mu^
(1/4)/a^(1/2))^(1/2))/(k/mu)^(1/2)/(k^(1/4)*mu^(1/4)/a^(1/2))^(1/2)
[...]
<-- exit simplify/sqrt/fraction (now in simplify/sqrt/global) = 1/2/mu^(1/2)/k^
(1/2)/(1/mu)^(1/2)}
                                       1
                            -----------------------
                                1/2   1/2 / 1  \1/2
                            2 mu    k~    |----|
                                          \ mu /

So, preliminary, if your computation involves assumptions and a call to this routine (as shown by trace), the result should be checked, I think. It remains to find the  mechanism by which the assumption generates this problem. Certainly, I have checked back this bug with earlier versions. On the other hand, I have not found so far a related report. So, probably it deserves a SCR.

I agree, this is a bug in simplify. A simple way to get the expected result is assuming at the second simplification:

> s:=(-hbar^2*(diff(diff(eta(0, x), x), x))
/(2*mu)+(1/2)*k*x^2*eta(0, x))/(omega*eta(0, x)): > s1:=simplify(s); /k mu \1/2 |-----| hbar | 2| \hbar / s1 := --------------- / k \1/2 2 |----| mu \ mu / > simplify(s1) assuming positive; 1/2 The current behavior seems to have appeared in Maple 10. Earlier it was even more odd...

OK, I think that now I understand better your point. It looks like a request for a command similar to Mathematica command ListPlot[sdata,Filling->Axis] shown here, where sdata is a Mathematica Table, equivalent to your pair of lists. By the way, line graph seems something else in English. And actually, plots:-pointplot may take a pair of lists, but it does not seem to have a similar option to "fill" from the axis to the point. So, I have sketched a procedure named filledpointplot:

> filledpointplot:=proc(l1::list,l2::list,
plotview::list:=[min(l1)-1..max(l1)+1,0..max(l2)*1.2],{linestyle::list:=[]}) > local f:=(a,b)->plottools:-curve([[a,0],[a,b]],op(linestyle)); > plots:-display(zip(f,l1,l2),view=plotview); > end proc: > > A1:=[3,5,7,2,11,1,10,6,15]: > B1:=[0.23, 0.11, 0.05, 0.11,0.04, 0.10, 0.20, 0.06, 0.10]: > > filledpointplot(A1,B1);

 

And it admits options to set line style and plot view like:

> filledpointplot(A1,B1,[0..10,0..0.4],linestyle=[color=red]);

I think that you may just save and use it until an equivalent facility is implemented in stock Maple.

I think that it is simpler to add frequencies and plot the lines, here using the CURVES data structure, but you could use plottools:-curve instead for handling options easily:

> A:=[3,5,7,2,11,2,1,10,6,15]:
> B:=[0.23, 0.11, 0.05, 0.05, 0.04, 0.06, 0.10, 0.20, 0.06, 0.10]:
> 
> C:=zip((a,b)->[a,b],A,B);
C := [[3, 0.23], [5, 0.11], [7, 0.05], [2, 0.05], [11, 0.04], [2, 0.06],
    [1, 0.10], [10, 0.20], [6, 0.06], [15, 0.10]]

> C1:=ListTools:-Classify(x->op(1,x),C); C1 := table([1 = {[1, 0.10]}, 2 = {[2, 0.05], [2, 0.06]}, 3 = {[3, 0.23]}, 5 = {[5, 0.11]}, 7 = {[7, 0.05]}, 6 = {[6, 0.06]}, 10 = {[10, 0.20]}, 11 = {[11, 0.04]}, 15 = {[15, 0.10]} ])
> C2:=convert(C1,list); C2 := [{[1, 0.10]}, {[2, 0.05], [2, 0.06]}, {[3, 0.23]}, {[5, 0.11]}, {[6, 0.06]}, {[7, 0.05]}, {[10, 0.20]}, {[11, 0.04]}, {[15, 0.10]}]
> C3:=map(x->`if`(nops(x)=1,op(x),[op([1,1],x),
`+`(seq(op([i,2],x),i=1..nops(x)))]),C2); C3 := [[1, 0.10], [2, 0.11], [3, 0.23], [5, 0.11], [6, 0.06], [7, 0.05], [10, 0.20], [11, 0.04], [15, 0.10]] > > f:=a->CURVES([[op(1,a),0],a]): > plots:-display(map(f,C3),view=[0..16,0..0.4]);

 

Actually, the convergence of this sum is rather slow (with the Levin u-transformation algorithm being used), as it needs 48 terms to converge. And to get them, Digits>=24 has to be set:

> infolevel[sum]:=4:
> A:=Sum(I^n*BesselJ(n,2*sqrt(34))*exp(-I*n*arctan(5/3))*exp(I*n*Pi/4),n=1..infinity):

> evalf[24](A); 
evalf/Sum/infinite:   the sum appears to have converged after    48    terms
           0.0540055204234803729319964 - 0.787375670007105789851047 I

Exactly the same number of terms is needed if the factor I^n were removed. I wonder why the internal value of Digits is not being raised automatically to the convergence range.

See this output for a possibly complete list of plotting devices, that includes png:

plotsetup(help);
Usage plotsetup(device,options).
The following device types are known:
 PostScript, X11, bmp, char, cps, default, dumb, dxf, eps, gdi, gif, hpgl, hplj, 
inline, jpeg, laserjet, maplet, pcx, png, postscript, pov, ps, tek, tektronix,
window, wmf, x11, xwindow

A SCR against the incompletness of the documentation on this subject, ?plot,device and family, was submitted years ago...I observe png in this output already for Maple 11.02.

I wonder what you did. There is a command, see ?plots,setoptions which works for some options but not for some other ones, including discont, what does not seem good for me.

See this thread for text editors of Maple source code. On the GUI side, see ?updates,Maple17,CodeEditor and the Maple IDE.

Execute in Maple 13:

kernelopts(opaquemodules=false):
trace(MultiSeries:-`multiseries/leadterm`):
T:=ln(ln(n))*(ln(n)*(n*(
       (abs(sin(n))/n^2)/(abs(sin(n+1))/(n+1)^2)-1)-1)-1);
MultiSeries:-limit(T, n=infinity);

You will see that the procedure MultiSeries:-`multiseries/leadterm` is being called recursively tens of times until a limit is reached, raising the exception that generates that error message.

Perhaps, programmatically, in the Standard GUI, you should go generating TypeMK structures. Something along this sketch:

tp:=proc()
local a:=seq(mi(i),i in args):
Typesetting:-mrow(a);
end proc:

tp("Vector([1, 2])"," is in S");
                     Vector([1, 2]) is in S

Yes, I think that this is a bug as the case when solve is not returning explicit solutions for the 4th degree polynomial seems not being taken into account. Another workaround is then forcing an explicit solution by setting:

_EnvExplicit := true:

This way, a somewhat lengthly expression occurs that can be plotted.

Yes, the up arrow key works like that in the CLI (Command Line Interface).

First 14 15 16 17 18 19 20 Last Page 16 of 29