@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

@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

@Markiyan Hirnyk Your timing is not valid because of remember tables. You have to test on different numbers. Here's a better test. Actually, doing the integration symbolically first is about 25 times faster using 512 evaluation points. 

Download Ei_integration_timin.mw

@Markiyan Hirnyk Your timing is not valid because of remember tables. You have to test on different numbers. Here's a better test. Actually, doing the integration symbolically first is about 25 times faster using 512 evaluation points. 

Download Ei_integration_timin.mw

If you're trying to solve with fsolve, then you need to drastically reduce the value of Digits.

If you're trying to solve with fsolve, then you need to drastically reduce the value of Digits.

Your g(x) reduces to g(x) = A, because of most-well-known trig identity: cos^2 + sin^2 = 1. So, there is not really any parameter C.

Nicely detailed plot!

I don't how clock faces usually appear in your culture, but I think that in most of the Western World the position that you have labeled as 0 is labeled as 12 (even though mathematicians and especially computer programmers must wish it was 0). It is so culturally ingrained that we refer to an distant object directly in front of us as "at 12 o'clock" and a distant overhead object as being "12 o'clock high".