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.

    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.

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

Download EI_plot.mw

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

Download EI_plot.mw

@matja You asked

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

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.

Download Constant_of_integrat.mw