Timeline for Determining which rule NIntegrate selects automatically
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Mar 4, 2016 at 23:22 | history | bounty ended | Michael E2 | ||
| S Mar 4, 2016 at 23:22 | history | notice removed | Michael E2 | ||
| S Feb 28, 2016 at 20:34 | history | bounty started | Michael E2 | ||
| S Feb 28, 2016 at 20:34 | history | notice added | Michael E2 | Reward existing answer | |
| Oct 10, 2015 at 10:37 | answer | added | Anton Antonov | timeline score: 41 | |
| Jun 13, 2013 at 4:33 | answer | added | Andrew Moylan | timeline score: 19 | |
| Jun 5, 2013 at 11:08 | history | tweeted | twitter.com/#!/StackMma/status/342236365813067776 | ||
| Jun 4, 2013 at 22:04 | comment | added | user7885 | Thanks. Surprisingly, NIntegrate complains about insufficient recursive bisections even when "MethodSwitching" is False. Does this mean NIntegrate is again falling back on GlobalAdaptive, or is the singularity at 0 causing a problem with Levin's collocation? ans = NIntegrate[Sin[x]^2 Sin[1000 x]^2/x^2.5, {x, 0, Infinity}, Method -> {"LevinRule", "MethodSwitching" -> False, "Kernel" -> Sin[1000 x]^2, "Points" -> 5}, PrecisionGoal -> 8] During evaluation of In[36]:= NIntegrate::ncvb: NIntegrate failed to converge to prescribed accuracy after 9 recursive bisections in x near {x} = {0.}. | |
| Jun 4, 2013 at 21:57 | comment | added | user7885 | ans = NIntegrate[Sin[x]^2 Sin[1000 x]^2/x^2.5, {x, 0, Infinity}, Method -> {"LevinRule", "MethodSwitching" -> False, "Kernel" -> Sin[1000 x]^2, "Points" -> 5}, PrecisionGoal -> 8] During evaluation of In[36]:= NIntegrate::ncvb: NIntegrate failed to converge to prescribed accuracy after 9 recursive bisections in x near {x} = {0.}. NIntegrate obtained 1.1675453364639328` and 0.00030762526309975006` for the integral and error estimates. >> Out[36]= 1.16754533646 | |
| Jun 4, 2013 at 18:49 | comment | added | J. M.'s missing motivation♦ |
In particular, you might be interested in the ExcludedForms option, if you choose the strategy of only considering the more oscillatory Sin[1000 x], while ignoring Sin[x]. If you take a look at the advanced documentation, there is also a pointer to the undocumented function NIntegrate`LevinIntegrandReduce[], which might help you in exploring how to properly set options.
|
|
| Jun 4, 2013 at 18:21 | comment | added | user7885 | Thanks for the advice. I'll experiment some more with the options for LevinRule, and hopefully Mathematica won't override my choices without letting me know :-) | |
| Jun 4, 2013 at 18:01 | comment | added | J. M.'s missing motivation♦ |
Well, as you've seen, "LevinRule" can be more efficient than the other two oscillatory methods, but it is rather finicky, and you need to do some fiddling sometimes.
|
|
| Jun 4, 2013 at 17:52 | comment | added | user7885 | Sorry--my previous comment was truncated. I didn't opt for the "ExtrapolatingOscillatory" or "DoubleExponentialOscillatory" rules because I will need to integrate this function over both finite intervals [0,a] as well as semi-infinite intervals [a,infinity]. Also, computation time for these rules should scale with frequency (w=1000 in the example I show) but not so for Levin. Nevertheless, having just tried it, I see that both the "ExtrapolatingOscillatory" and "DoubleExponentialOscillatory" rules in Mathematica do give fast and accurate results even for w=100,000. | |
| Jun 4, 2013 at 17:46 | comment | added | J. M.'s missing motivation♦ |
BTW: in fact, the default method used by NIntegrate[] for "nice" integrals is "GlobalAdaptive"; as you've noticed, it is the method being used instead of "LevinRule", somewhat sneakily...
|
|
| Jun 4, 2013 at 17:41 | history | edited | J. M.'s missing motivation♦ | CC BY-SA 3.0 |
added 58 characters in body
|
| Jun 4, 2013 at 17:40 | comment | added | user7885 | Thanks for the quick response! There are a few reasons I didn't use "ExtrapolatingOscillatory" or "DoubleExponentialOscillatory" from the start. First, I will need to integrate this function over both finite intervals [0,a] as well as semi-infinite intervals [a,infinity], with a>0. Second, I had previously implemented both of these rules from scratch in IDL and found that both require too much computation time when the frequency (1000 in the example I show here) increases. For example, to compute | |
| Jun 4, 2013 at 17:34 | review | First posts | |||
| Jun 4, 2013 at 17:44 | |||||
| Jun 4, 2013 at 17:29 | history | edited | J. M.'s missing motivation♦ |
edited tags
|
|
| Jun 4, 2013 at 17:26 | history | edited | Szabolcs | CC BY-SA 3.0 |
added 105 characters in body
|
| Jun 4, 2013 at 17:20 | comment | added | J. M.'s missing motivation♦ |
Why not use, say, "ExtrapolatingOscillatory" or "DoubleExponentialOscillatory" instead, since your oscillatory integral is over $[0,\infty)$ anyway?
|
|
| Jun 4, 2013 at 17:15 | history | asked | user7885 | CC BY-SA 3.0 |