Carl Love

## 26089 Reputation

11 years, 54 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

## dfieldplot?...

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

## You can now "like"...

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

## You can now "like"...

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

## We were daunted by the sheer simplicity ...

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 were daunted by the sheer simplicity ...

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.

## "preferably a line"?...

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.

## Explanation of timing and remembered val...

@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;

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

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

## Explanation of timing and remembered val...

@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;

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

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

## Yes, but that's an IVP...

@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.

## Yes, but that's an IVP...

@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.

## Indefinite integrals cannot be numerical...

@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

## Indefinite integrals cannot be numerical...

@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

## ln(2) is constant of integration...

...which differs from mathematica in the particular solution, there is on more term, namely: 2*r*exp(-r)*ln(2) which is already covered in the term r exp(-r)*_C2 of the general solution. What could be said to this?

If you put the new differential equation into the worksheet that I posted and run through the steps, then I think you'll see what's going on. The integration generates a term -ln(2*r), which becomes -ln(2) - ln(r) on simplification. One way to think of it is that the indefinite integral produces a constant of integration, but the int command does not supply an arbitrary constant . Since there are already two constants provided by dsolve, it is necessary that this extra constant matches up with a term which already has one of the dsolve-supplied constants. I guess that this can be used as a sort of accuracy check.

Maple's indefinite integration usually, but not always, produces 0 as the constant of integration; it depends on what is convenient. Here's a simple example, pretty close to the case at hand, where it doesn't.

 > int(ln(2*x)/x, x);

 > expand(%);

Clearly 1/2*ln(2)^2 is a more convenient constant than 0 for the unexpanded form in this case.

Plaese let me know whether this explanation satisfies you.