Sage: Ticket #7763: make nintegrate/nintegral top-level functions
https://trac.sagemath.org/ticket/7763
<p>
We just need to add them to sage/devel/sage/misc/functional.py. Modifying the versions of integrate/integral in that file would probably be easiest.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/7763
Trac 1.1.6jasonWed, 26 May 2010 15:16:59 GMTkeywords set
https://trac.sagemath.org/ticket/7763#comment:1
https://trac.sagemath.org/ticket/7763#comment:1
<ul>
<li><strong>keywords</strong>
<em>beginner</em> added
</li>
</ul>
TicketkcrismanWed, 26 May 2010 17:42:54 GMTcc set
https://trac.sagemath.org/ticket/7763#comment:2
https://trac.sagemath.org/ticket/7763#comment:2
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
</ul>
TicketryanSat, 11 Sep 2010 23:02:43 GMT
https://trac.sagemath.org/ticket/7763#comment:3
https://trac.sagemath.org/ticket/7763#comment:3
<p>
Is this supposed to be a numerical approximation of the integral function?
</p>
TicketkcrismanSat, 11 Sep 2010 23:58:01 GMT
https://trac.sagemath.org/ticket/7763#comment:4
https://trac.sagemath.org/ticket/7763#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7763#comment:3" title="Comment 3">ryan</a>:
</p>
<blockquote class="citation">
<p>
Is this supposed to be a numerical approximation of the integral function?
</p>
</blockquote>
<p>
No, this is an existing method of symbolic functions, which uses a different algorithm to get a numerical integral. But you can only call it in
</p>
<pre class="wiki">sage: f(x)=some_formula_with_x
sage: f.nintegrate(...)
</pre><p>
not as a top-level
</p>
<pre class="wiki">nintegral(f,...)
</pre><p>
type function.
</p>
<p>
We should also probably make the syntax like that of <code>numerical_integral</code> *and* make that syntax consistent (at least as an option) with that of <code>integral</code> itself (see ask.sagemath.org for various problems this causes).
</p>
TicketgagansekhonTue, 11 Jan 2011 01:31:14 GMTstatus changed
https://trac.sagemath.org/ticket/7763#comment:5
https://trac.sagemath.org/ticket/7763#comment:5
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketkcrismanTue, 11 Jan 2011 03:58:49 GMTstatus changed; reviewer, author set
https://trac.sagemath.org/ticket/7763#comment:6
https://trac.sagemath.org/ticket/7763#comment:6
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman</em>
</li>
<li><strong>author</strong>
set to <em>Gagan Sekhon</em>
</li>
</ul>
<p>
There are two issues with this. First, because of the extreme possibility for confusion with the already top-level <code>numerical_integral</code>function, this will need some work in documentation. See some of the documentation in
</p>
<pre class="wiki">sage: sage.calculus.calculus.nintegral??
</pre><p>
for what I mean. I don't think all of that needs to be there, but there should then be a reference for how to access the rest of it. Basically, Maxima numerical integration and GSL numerical integration are different. In particular, one would want to use Maxima for symbolic expressions - in case there is an exact answer known! - and then have a variety of options for numerical integration if that fails.
</p>
<p>
Anyway, that was a longish digression. More importantly, this patch doesn't exactly do what is asked. The point isn't to be able to approximate exact answers to integrals, but rather to expose to the top level the Maxima integration.
</p>
<pre class="wiki">sage: a = e^(-x^4 + x)
sage: a.nintegral(x,0,1)
(1.3638178766496709, 1.5141420080518571e-14, 21, 0)
sage: integral(a,(x,0,1)).n()
1.3638178766496716
</pre><p>
Note the slight difference in output, incidentally - presumably within the error tolerance, of course. This is because we apparently have a THIRD way to evaluate integrals - Pynac!
</p>
<pre class="wiki">sage: R = RealField(53)
sage: integral(a,(x,0,1))._convert(R)
1.3638178766496716
</pre><p>
If you check the code for <code>_convert</code>, it turns out this goes to Pynac. See <a class="ext-link" href="http://www.ginac.de/reference/integral_8cpp_source.html#l00169"><span class="icon"></span>here</a> for some of how this happens in Ginac... crazy. We really need to unify this. But at any rate, we shouldn't use two different algorithms and do two different things for the same name <code>nintegrate</code>.
</p>
<p>
Anyone have ideas for what the best resolution on this would be?
</p>
<p>
Oh, and just for comparison:
</p>
<pre class="wiki">sage: numerical_integral(a,0,1)
(1.3638178766496716, 1.5141420080518571e-14)
</pre>
TicketkcrismanTue, 11 Jan 2011 03:59:31 GMT
https://trac.sagemath.org/ticket/7763#comment:7
https://trac.sagemath.org/ticket/7763#comment:7
<p>
And of course a more informative commit message :)
</p>
<p>
Don't worry, this is on the way to being a good contribution; we just have to figure out what the right thing to do is.
</p>
TicketgagansekhonTue, 11 Jan 2011 04:42:18 GMT
https://trac.sagemath.org/ticket/7763#comment:8
https://trac.sagemath.org/ticket/7763#comment:8
<p>
Thank you, this actually gives me a better project and finding random tickets. I will try doing what you asked here.
</p>
TicketgagansekhonWed, 12 Jan 2011 06:02:53 GMT
https://trac.sagemath.org/ticket/7763#comment:9
https://trac.sagemath.org/ticket/7763#comment:9
<p>
There are two different inconsistency
</p>
<p>
numerical_integral is top level only function and it uses gsl
</p>
<p>
nintegral is not top level and uses maxima
</p>
<p>
for consistency purpose I was thinking of doing the following:
</p>
<ol><li>to both add algorithm input, (the default would be gsl for top level and maxima for non-top level)
</li></ol><ol start="2"><li>make both functions top level and methods
</li></ol><p>
Any thoughts?
</p>
TicketgagansekhonWed, 12 Jan 2011 06:33:44 GMT
https://trac.sagemath.org/ticket/7763#comment:10
https://trac.sagemath.org/ticket/7763#comment:10
<p>
As for other *integra* all have either no algorithm option and uses maxima or only uses maxima. Still thinking the least complicated way to clean this up with most flexibility.
</p>
TicketkcrismanWed, 12 Jan 2011 15:38:09 GMTcc changed
https://trac.sagemath.org/ticket/7763#comment:11
https://trac.sagemath.org/ticket/7763#comment:11
<ul>
<li><strong>cc</strong>
<em>jason</em> <em>mhampton</em> added
</li>
</ul>
<p>
Maybe the best thing to do would be to have ONE top level function for numerical integration (<code>numerical_integral</code>), of which <code>nintegrate</code> and <code>nintegral</code> would be aliases. Then one would have to really at this time change the syntax of <code>numerical_integral</code> so that it accepts the same syntax as integration in general does; you'll notice that currently it does not accept a variable, only the endpoints:
</p>
<pre class="wiki"> if hasattr(func, 'arguments'):
vars = func.arguments()
else:
vars = func.variables()
</pre><p>
so that it guesses what the correct variable is. It also makes it really hard to do numerical integration on the fly with it, because you can't do <a class="ext-link" href="http://ask.sagemath.org/question/95/numerical-integration-in-a-function"><span class="icon"></span>this</a> very easily.
</p>
<p>
In that case, it would be easy to have several different algorithms. I don't know which would be better; in some sense, it would be best to always first see if we get an exact answer from Maxima, and if not, then do a numerical integral. Or should it always do a straight-up numerical integral (whether from GSL, Maxima, <a class="missing wiki">Gi/Pynac?</a>...)?
</p>
<p>
As you can see, even trying to solve pretty 'easy' tickets can open a can of worms! Keep up the effort, though, it is much appreciated.
</p>
TicketgagansekhonThu, 13 Jan 2011 18:43:16 GMT
https://trac.sagemath.org/ticket/7763#comment:12
https://trac.sagemath.org/ticket/7763#comment:12
<p>
I am still working on this, but wanted to add a patch to show the progress.
</p>
TicketgagansekhonThu, 13 Jan 2011 18:44:18 GMT
https://trac.sagemath.org/ticket/7763#comment:13
https://trac.sagemath.org/ticket/7763#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7763#comment:12" title="Comment 12">gagansekhon</a>:
</p>
<blockquote class="citation">
<p>
I am still working on this, but wanted to add a patch to show the progress.
</p>
</blockquote>
<p>
the new patch integration.patch has the new and only progress.
</p>
TicketkcrismanThu, 13 Jan 2011 19:15:09 GMT
https://trac.sagemath.org/ticket/7763#comment:14
https://trac.sagemath.org/ticket/7763#comment:14
<p>
Thanks, good to see this!
</p>
<p>
I would caution that for annoying reasons we like to have the lines in the documentation be fairly short; see some of the other calculus or plotting files for examples of about how many characters (80? 84?) are appropriate. (Otherwise it looks really bad in command line.) So any updates should fix that.
</p>
TicketgagansekhonSun, 16 Jan 2011 21:37:53 GMTattachment set
https://trac.sagemath.org/ticket/7763
https://trac.sagemath.org/ticket/7763
<ul>
<li><strong>attachment</strong>
set to <em>integration.patch</em>
</li>
</ul>
TicketgagansekhonMon, 17 Jan 2011 17:15:18 GMTattachment set
https://trac.sagemath.org/ticket/7763
https://trac.sagemath.org/ticket/7763
<ul>
<li><strong>attachment</strong>
set to <em>trac_7763.6.patch</em>
</li>
</ul>
TicketgagansekhonMon, 17 Jan 2011 17:15:30 GMTstatus changed
https://trac.sagemath.org/ticket/7763#comment:15
https://trac.sagemath.org/ticket/7763#comment:15
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
TicketgagansekhonMon, 17 Jan 2011 17:16:12 GMT
https://trac.sagemath.org/ticket/7763#comment:16
https://trac.sagemath.org/ticket/7763#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7763#comment:15" title="Comment 15">gagansekhon</a>:
apply trac_7763.patch only
</p>
TicketgagansekhonMon, 17 Jan 2011 17:16:28 GMTattachment set
https://trac.sagemath.org/ticket/7763
https://trac.sagemath.org/ticket/7763
<ul>
<li><strong>attachment</strong>
set to <em>trac_7763.7.patch</em>
</li>
</ul>
TicketkcrismanMon, 17 Jan 2011 17:22:20 GMT
https://trac.sagemath.org/ticket/7763#comment:17
https://trac.sagemath.org/ticket/7763#comment:17
<p>
To buildbot: apply trac_7763.7.patch only.
</p>
<p>
(I think that the .6 and .7 patches must be identical, but it doesn't matter.)
</p>
TicketgagansekhonTue, 18 Jan 2011 02:31:48 GMT
https://trac.sagemath.org/ticket/7763#comment:18
https://trac.sagemath.org/ticket/7763#comment:18
<p>
Trac_7763.8.patch is the patch with everything, including commit line.
</p>
TicketkcrismanTue, 18 Jan 2011 16:09:48 GMTstatus changed; keywords deleted
https://trac.sagemath.org/ticket/7763#comment:19
https://trac.sagemath.org/ticket/7763#comment:19
<ul>
<li><strong>keywords</strong>
<em>beginner</em> removed
</li>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Again, a good start at this!
</p>
<p>
Unfortunately, there are now MANY small issues that need to be cleared up before testing and positive review can occur. I don't see any of these as insurmountable. However, I'm definitely removing the 'beginner' tag, given that this has become a more subtle ticket.
</p>
<p>
First, there are still a fair number of typos, English issues like <code>every floating point evaluation of return</code> (which was in the original, not introduced by the author of the patch, but should be fixed), etc. There should be better formatting (<code>Examples::</code> should be capitalized, for example), and hopefully links to the functions put in - see the plotting functions, especially plot.py, for examples of how to do that in Sphinx.
</p>
<blockquote class="citation">
<p>
I would caution that for annoying reasons we like to have the lines in the documentation be fairly short; see some of the other calculus or plotting files for examples of about how many characters (80? 84?) are appropriate. (Otherwise it looks really bad in command line.) So any updates should fix that.
</p>
</blockquote>
<p>
This comment still applies.
</p>
<p>
Another interesting thing is the use of <code>*args</code> and <code>**kwds</code>. Really, we expect only a few cases of args, and only one keyword. I think the syntax for this should be like for symbolic integrals, e.g. <code>f.integrate(algorithm="mathematica_free")</code> - that is to say, maybe it should be <code>algorithm</code> instead of <code>alg</code>. Maybe even specifically check the args? I don't know.
</p>
<p>
The private function <code>_numerical_integral</code> needs documentation.
</p>
<pre class="wiki">#This is so the old numerical_integral will still work
</pre><p>
is not quite accurate, as it's doing more than that :)
</p>
<p>
I'm not sure whether the Mma or sympy ones actually will return numerical values. Also, one should doctest all those options.
</p>
<p>
What is the idea with calling the other numerical integral (from Maxima) <code>_nintegral_sym</code>, since it's not symbolic? Maybe I'm missing something.
</p>
<p>
I think you now have <code>Note that in exotic cases</code> twice in the same docstring - is that correct?
</p>
<p>
Anyway, all doable things, and the final produce will be quite valuable.
</p>
<p>
(As a final comment, it would be worth seeing whether the issues at <a class="ext-link" href="http://ask.sagemath.org/question/95/numerical-integration-in-a-function"><span class="icon"></span>this discussion</a> are solved with this ticket. I don't believe so - since these integrals aren't made symbolic - but it's worth checking.)
</p>
TicketgagansekhonWed, 19 Jan 2011 21:57:24 GMT
https://trac.sagemath.org/ticket/7763#comment:20
https://trac.sagemath.org/ticket/7763#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7763#comment:19" title="Comment 19">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Again, a good start at this!
</p>
<p>
Unfortunately, there are now MANY small issues that need to be cleared up before testing and positive review can occur. I don't see any of these as insurmountable. However, I'm definitely removing the 'beginner' tag, given that this has become a more subtle ticket.
</p>
<p>
First, there are still a fair number of typos, English issues like <code>every floating point evaluation of return</code> . (which was in the original, not introduced by the author of the patch, but should be fixed), etc.
</p>
</blockquote>
<p>
I have read this line several time and can't figure out what it is trying to say, perhaps someone else can tell me what it should be.
</p>
<blockquote>
<p>
There should be better formatting (<code>Examples::</code> should be capitalized, for example),
</p>
</blockquote>
<p>
Fixed
</p>
<blockquote>
<p>
and hopefully links to the functions put in - see the plotting functions, especially plot.py, for examples of how to do that in Sphinx.
</p>
<blockquote class="citation">
</blockquote>
</blockquote>
<p>
Did you want links each function listed in the file? Like a table of contents.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I would caution that for annoying reasons we like to have the lines in the documentation be fairly short; see some of the other calculus or plotting files for examples of about how many characters (80? 84?) are appropriate. (Otherwise it looks really bad in command line.) So any updates should fix that.
</p>
</blockquote>
<p>
This comment still applies.
</p>
</blockquote>
<p>
I tried to make the lines shorter, but the html file looked wierd. Html file formats each line and wraps it around. If I make them them shorter the documentation doesn't come out right.
</p>
<blockquote class="citation">
<p>
Another interesting thing is the use of <code>*args</code> and <code>**kwds</code>. Really, we expect only a few cases of args, and only one keyword.
</p>
</blockquote>
<p>
Actually, there are several different sets of keywords depending on the algorithm provided.
</p>
<blockquote>
<p>
I think the syntax for this should be like for symbolic integrals, e.g. <code>f.integrate(algorithm="mathematica_free")</code> - that is to say, maybe it should be <code>algorithm</code> instead of <code>alg</code>. Maybe even specifically check the args? I don't know.
</p>
</blockquote>
<p>
The reason I went with alg, was that for alg="gsl", algorithm is one of the keywords already being used.
</p>
<blockquote class="citation">
<p>
The private function <code>_numerical_integral</code> needs documentation.
</p>
</blockquote>
<p>
added
</p>
<blockquote class="citation">
<pre class="wiki">#This is so the old numerical_integral will still work
</pre><p>
is not quite accurate, as it's doing more than that :)
</p>
<p>
I'm not sure whether the Mma or sympy ones actually will return numerical values. Also, one should doctest all those options.
</p>
</blockquote>
<p>
I tested mma and you are right it gives an error, though the actual function it is calling makes it seem like it should work.
</p>
<p>
Sympy, however does return numerical values for symbolic functions with closed form.
</p>
<p>
Added doctest for all algorithms
</p>
<blockquote class="citation">
<p>
What is the idea with calling the other numerical integral (from Maxima) <code>_nintegral_sym</code>, since it's not symbolic? Maybe I'm missing something.
</p>
</blockquote>
<p>
This used to be nintegral and is imported by symbolic.integration for f.nintegral. I kept this because it has different output than numerical_integral (both old and new)
</p>
<blockquote class="citation">
<p>
I think you now have <code>Note that in exotic cases</code> twice in the same docstring - is that correct?
</p>
</blockquote>
<p>
This was already there, I will read the documentation for that function and see if it is still needed.
</p>
<blockquote class="citation">
<p>
Anyway, all doable things, and the final produce will be quite valuable.
</p>
<p>
(As a final comment, it would be worth seeing whether the issues at <a class="ext-link" href="http://ask.sagemath.org/question/95/numerical-integration-in-a-function"><span class="icon"></span>this discussion</a> are solved with this ticket. I don't believe so - since these integrals aren't made symbolic - but it's worth checking.)
</p>
</blockquote>
<p>
This is still open, but if one uses integral instead of numerical_integral it works. Since the result until the numerical values are inputed is not numeric, but a function in x, and y , numerical_integral should perhaps not be used.
</p>
TicketgagansekhonWed, 19 Jan 2011 21:57:43 GMTattachment set
https://trac.sagemath.org/ticket/7763
https://trac.sagemath.org/ticket/7763
<ul>
<li><strong>attachment</strong>
set to <em>trac_7763.8.patch</em>
</li>
</ul>
TicketkcrismanWed, 19 Jan 2011 22:08:16 GMT
https://trac.sagemath.org/ticket/7763#comment:21
https://trac.sagemath.org/ticket/7763#comment:21
<p>
Thanks for clearing up some of my misunderstandings. I don't have time to look at this today, but hopefully within a week? Just a couple clarifications:
</p>
<blockquote class="citation">
<blockquote>
<p>
and hopefully links to the functions put in - see the plotting functions, especially plot.py, for examples of how to do that in Sphinx.
</p>
<blockquote class="citation">
</blockquote>
</blockquote>
<p>
Did you want links each function listed in the file? Like a table of contents.
</p>
</blockquote>
<p>
I mean like <code>:func:`~sage.plot.plot.plot`</code> referring to the function <code>plot</code>; one can do the same here, I think.
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
I would caution that for annoying reasons we like to have the lines in the documentation be fairly short; see some of the other calculus or plotting files for examples of about how many characters (80? 84?) are appropriate. (Otherwise it looks really bad in command line.) So any updates should fix that.
</p>
</blockquote>
<p>
This comment still applies.
</p>
</blockquote>
<p>
I tried to make the lines shorter, but the html file looked wierd. Html file formats each line and wraps it around. If I make them them shorter the documentation doesn't come out right.
</p>
</blockquote>
<p>
Hmm, that's odd. I'll have to check it out; in most files we do this. Maybe we've just been living with weird HTML :)
</p>
TicketkcrismanMon, 18 Apr 2011 15:25:08 GMT
https://trac.sagemath.org/ticket/7763#comment:22
https://trac.sagemath.org/ticket/7763#comment:22
<p>
See also <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/8321" title="defect: numerical integration with arbitrary precision (needs_work)">#8321</a>. We continue to get support requests because of the non-unified nature of our options.
</p>
TicketkcrismanWed, 12 Oct 2011 12:21:21 GMT
https://trac.sagemath.org/ticket/7763#comment:23
https://trac.sagemath.org/ticket/7763#comment:23
<p>
It turns out that the current top-level function, <code>numerical_integral</code>, isn't even in the reference manual. See <a class="closed ticket" href="https://trac.sagemath.org/ticket/11916" title="enhancement: add numerical integration to reference manual (closed: duplicate)">#11916</a>. I don't think this is addressed here yet, though if it eventually is then that ticket would be closed as a dup.
</p>
TicketjdemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/7763#comment:24
https://trac.sagemath.org/ticket/7763#comment:24
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/7763#comment:25
https://trac.sagemath.org/ticket/7763#comment:25
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/7763#comment:26
https://trac.sagemath.org/ticket/7763#comment:26
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
Ticketvbraun_spamSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/7763#comment:27
https://trac.sagemath.org/ticket/7763#comment:27
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
Ticket