Carl Love

Carl Love

27651 Reputation

25 Badges

12 years, 123 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

There haven't been any updates to Maple since 18-Nov-2012. (The date the update actually reaches your computer may vary from that.) You can check if yours has been updated by using the command kernelopts(version).

In the case posed in the original question, the absence of the multiplication operator turns the expression into nonsense. The fact that Maple has some response to it other than an outright error message is just bad luck.

Please post your worksheet in a separate thread, i.e. as a new Question.

There haven't been any updates to Maple since 18-Nov-2012. (The date the update actually reaches your computer may vary from that.) You can check if yours has been updated by using the command kernelopts(version).

In the case posed in the original question, the absence of the multiplication operator turns the expression into nonsense. The fact that Maple has some response to it other than an outright error message is just bad luck.

Please post your worksheet in a separate thread, i.e. as a new Question.

Are you using the command dfieldplot? Post the actual command that you used.

@9colai You can now give Joe a "like" if you like. You now have the required 10 points.

@9colai You can now give Joe a "like" if you like. You now have the required 10 points.

We, in attempting to answer the question, were daunted by the sheer simplicity of it. I did not open the worksheet until I saw your answer. Yes, I'll bet that you're right: It was simply a matter of semicolon versus colon.

We, in attempting to answer the question, were daunted by the sheer simplicity of it. I did not open the worksheet until I saw your answer. Yes, I'll bet that you're right: It was simply a matter of semicolon versus colon.

What do you mean by "preferably a line, the 1s being on one side and the 2s the other"? Perhaps you could draw a picture on paper of what you want and photograh it and upload it. I suspect that what you want would be fairly easy to do.

@jmw193 Please post this as a separate question, i.e. in a new thread, and I will gladly answer it then.

@jmw193 Please post this as a separate question, i.e. in a new thread, and I will gladly answer it then.

@Markiyan Hirnyk When you repeatedly evaluate an expression using the same values for the parameters, Maple can often remember part or all of the computation that has already been done. So the time for the subsequent evaluations is much less than the time for the initial evaluation. In actual usage, a function is more likely to be evaluated at 1000 different values than to be evaluated 1000 times at the same value, so the former provides a more valid test. In this case, I haven't been able to find the actual remember tables. However, the tests clearly show that there is a huge difference between evaluating at different points and evaluating at the same point.

A practical example showing the timing difference between the evaluated-integral solution and the unevaluated-integral solution of the problem at hand is to plot them, because this will evaluate the expressions at a few hundred different points.

PatrickT did not take this into consideration in his tests, which makes those tests somewhat suspicious. However, those tests were mostly of low-level computations in the kernel where this "memoisation" effect is less likely to be significant.

In conclusion, it is always better to perform an experiment on a random sample of data.

restart;

DQ:= -((D@@2)(y))(r)-2*y(r)/r+y(r) = ((4/9-exp(-r)/r)*2)*r*exp(-r):

Y:= rhs(dsolve({DQ, y(1)=1, D(y)(1)=2}, y(r))):

Y1:= simplify(Y):

CodeTools:-Usage(evalf(eval(Y1, r= 2.))):

memory used=12.62MiB, alloc change=4.00MiB, cpu time=125.00ms, real time=240.00ms

CodeTools:-Usage(evalf(eval(Y1, r= 2.))):

memory used=72.95KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns

CodeTools:-Usage(evalf(eval(Y1, r= 2.)), iterations= 2^9):

memory used=25.04KiB, alloc change=0 bytes, cpu time=273.44us, real time=273.44us

CodeTools:-Usage(evalf(eval(Y1, r= 3.))):

memory used=4.94MiB, alloc change=0 bytes, cpu time=47.00ms, real time=49.00ms

CodeTools:-Usage(evalf(eval(Y1, r= 3.))):

memory used=81.23KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns

CodeTools:-Usage(evalf(eval(Y1, r= 3.)), iterations= 2^9):

memory used=25.20KiB, alloc change=0 bytes, cpu time=275.39us, real time=273.44us

 

Time comparison using plots

Y2:= simplify(value(applyrule(Ei(1,_X::algebraic)= -Ei(-_X), Y1))):

CodeTools:-Usage(assign('P2', plot(Y2, r= 1..9))):

memory used=33.83MiB, alloc change=8.00MiB, cpu time=328.00ms, real time=629.00ms

CodeTools:-Usage(assign('P1', plot(Y1, r= 1..9))):

memory used=0.97GiB, alloc change=24.00MiB, cpu time=9.59s, real time=9.33s

9.59/.328;

29.2378048780488

plots:-display( < P1 | P2 > );

 

Arrays of plots won't upload, but the plots look the same.

 

 

 

    Download Ei_integration_timin.mw

@Markiyan Hirnyk When you repeatedly evaluate an expression using the same values for the parameters, Maple can often remember part or all of the computation that has already been done. So the time for the subsequent evaluations is much less than the time for the initial evaluation. In actual usage, a function is more likely to be evaluated at 1000 different values than to be evaluated 1000 times at the same value, so the former provides a more valid test. In this case, I haven't been able to find the actual remember tables. However, the tests clearly show that there is a huge difference between evaluating at different points and evaluating at the same point.

A practical example showing the timing difference between the evaluated-integral solution and the unevaluated-integral solution of the problem at hand is to plot them, because this will evaluate the expressions at a few hundred different points.

PatrickT did not take this into consideration in his tests, which makes those tests somewhat suspicious. However, those tests were mostly of low-level computations in the kernel where this "memoisation" effect is less likely to be significant.

In conclusion, it is always better to perform an experiment on a random sample of data.

restart;

DQ:= -((D@@2)(y))(r)-2*y(r)/r+y(r) = ((4/9-exp(-r)/r)*2)*r*exp(-r):

Y:= rhs(dsolve({DQ, y(1)=1, D(y)(1)=2}, y(r))):

Y1:= simplify(Y):

CodeTools:-Usage(evalf(eval(Y1, r= 2.))):

memory used=12.62MiB, alloc change=4.00MiB, cpu time=125.00ms, real time=240.00ms

CodeTools:-Usage(evalf(eval(Y1, r= 2.))):

memory used=72.95KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns

CodeTools:-Usage(evalf(eval(Y1, r= 2.)), iterations= 2^9):

memory used=25.04KiB, alloc change=0 bytes, cpu time=273.44us, real time=273.44us

CodeTools:-Usage(evalf(eval(Y1, r= 3.))):

memory used=4.94MiB, alloc change=0 bytes, cpu time=47.00ms, real time=49.00ms

CodeTools:-Usage(evalf(eval(Y1, r= 3.))):

memory used=81.23KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns

CodeTools:-Usage(evalf(eval(Y1, r= 3.)), iterations= 2^9):

memory used=25.20KiB, alloc change=0 bytes, cpu time=275.39us, real time=273.44us

 

Time comparison using plots

Y2:= simplify(value(applyrule(Ei(1,_X::algebraic)= -Ei(-_X), Y1))):

CodeTools:-Usage(assign('P2', plot(Y2, r= 1..9))):

memory used=33.83MiB, alloc change=8.00MiB, cpu time=328.00ms, real time=629.00ms

CodeTools:-Usage(assign('P1', plot(Y1, r= 1..9))):

memory used=0.97GiB, alloc change=24.00MiB, cpu time=9.59s, real time=9.33s

9.59/.328;

29.2378048780488

plots:-display( < P1 | P2 > );

 

Arrays of plots won't upload, but the plots look the same.

 

 

 

    Download Ei_integration_timin.mw

@Markiyan Hirnyk Yes, but in that example you've made the Asker's original problem into an IVP. For an IVP, dsolve does not leave an indefinite integral in the solution; it leaves an unevaluated definite integral. Other than extra CPU time usage, there is no problem with the numerical evaluation of the latter.

@Markiyan Hirnyk Yes, but in that example you've made the Asker's original problem into an IVP. For an IVP, dsolve does not leave an indefinite integral in the solution; it leaves an unevaluated definite integral. Other than extra CPU time usage, there is no problem with the numerical evaluation of the latter.

@Markiyan Hirnyk The inconvenience of having an indefinite integral in a dsolve solution is that it can't be numerically evaluated in a convenient way. Here's an example of plotting. Here I use the Asker's new version of the ODE, for which dsolve produces essentially the same indefinite integral.

restart;

DQ:= -((D@@2)(y))(r)-2*y(r)/r+y(r) = (2*(2-1/r^2))*r*exp(-r):

Y:= rhs(dsolve(DQ, y(r))):

YY:= simplify(value(subs(Ei(1,-2*r)= -Ei(2*r), Y))):

plot(eval(YY, [_C1= 0, _C2= 0]), r= 1..9);

plot(eval(Y, [_C1= 0, _C2= 0]), r= 1..9);

Warning, unable to evaluate the function to numeric values in the region; see the plotting command's help page to ensure the calling sequence is correct


Download EI_plot.mw

First 680 681 682 683 684 685 686 Last Page 682 of 704