New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
integration not working #10550
Comments
comment:1
Seems like there might be two issues here. One is that the default for integrate_numerical (which is what I think gets called here after symbolic integration fails) only uses a maximum of 87 sample points. This parameter can be set by using integrate_numerical directly but I don't think it can be through integrate. The second possible issue is that it seems that integrate_numerical tries to create a fast version of the function, but this is not done in an accurate way. I believe this code was written prior to fast_callable, which seems to help:
|
comment:2
It might also be worth noting that integrating over the entire real line is special-cased by integrate_numerical, so we get:
This is a little low, Mathematica gives 12.6195 but its hard to improve the precision. This is an intrinsically hard sort of problem to automate (but we can clearly improve the current behavior). |
comment:3
The reason this is broken is because the implementation of the method
|
comment:4
My personal opinion is that it should work like this:
Or maybe not. I hate this. |
comment:5
Mike Hansen: One option -- just rewrite |
comment:6
Be sure to use fast_callable:
|
comment:7
some more information about integration in mpmath and other programs http://groups.google.com/group/mpmath/browse_thread/thread/2fb6d36501c49a73 |
comment:8
Your timings with fast_callable seem misleading to me since you are not including the overhead of constructing the fast callable. I got:
|
comment:9
Not entirely misleading though, if you call the fast_callable many many times, as would seem to be the case here. |
comment:10
Getting this right will be tricky. While simply changing from a blind application of gsl's numerical_integral() to mpmath's quad() may be often be an improvement, in this situation it makes things worse:
Switching from tanh-sinh quadrature to Gauss-Legendre gives
Hand-tuning with Gauss-Legendre:
And with tanh-sinh:
It seems this integral requires at least some hand tuning to be reasonable. |
comment:11
There's probably a whole class of functions -- positive functions with a singularities at a finite number of points that go to zero sufficiently fast at plus/minus infinity maybe -- which exhibit this sort of breakage. |
comment:12
I tried gp
and got 7.9618235972792581897233298717819451083 |
comment:13
Just for the record, if given enough precision and the singularity locations, mpmath does okay in tanh-sinh on the infinite range:
and plotting it shows a very plausible logarithmic decrease in the size of the change (can't really call it an error..) You have to give it way more digits of precision than it actually gets right, but it's possible that it converged in the end. |
comment:15
Burcin, I think that this might be a dupe of #8321, at least for practical purposes. What do you think? |
Reviewer: Burcin Erocal |
Author: Karl-Dieter Crisman |
comment:16
Yep, this is a duplicate. I suggest we close this. I'll write a comment on #8321 so the discussion here is not lost. We were looking for examples on that ticket. It would be great if the examples here could be transferred somehow. Any volunteers? |
Changed author from Karl-Dieter Crisman to none |
Changed reviewer from Burcin Erocal to Karl-Dieter Crisman, Burcin Erocal |
Values should increase as g is a positive function!
CC: @kcrisman @burcin
Component: calculus
Reviewer: Karl-Dieter Crisman, Burcin Erocal
Issue created by migration from https://trac.sagemath.org/ticket/10550
The text was updated successfully, but these errors were encountered: