#7763: make nintegrate/nintegral top-level functions
-----------------------------------+----------------------------------------
Reporter: jason | Owner: burcin
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.6.2
Component: calculus | Keywords:
Author: Gagan Sekhon | Upstream: N/A
Reviewer: Karl-Dieter Crisman | Merged:
Work_issues: |
-----------------------------------+----------------------------------------
Comment(by gagansekhon):
Replying to [comment:19 kcrisman]:
> Again, a good start at this!
>
> 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.
>
> First, there are still a fair number of typos, English issues like
`every floating point evaluation of return` . (which was in the original,
not introduced by the author of the patch, but should be fixed), etc.
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.
There should be better formatting (`Examples::` should be capitalized,
for example),
Fixed
and hopefully links to the functions put in - see the plotting functions,
especially plot.py, for examples of how to do that in Sphinx.
>
Did you want links each function listed in the file? Like a table of
contents.
> > 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.
>
> This comment still applies.
>
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.
> Another interesting thing is the use of `*args` and `**kwds`. Really,
we expect only a few cases of args, and only one keyword.
Actually, there are several different sets of keywords depending on the
algorithm provided.
I think the syntax for this should be like for symbolic integrals, e.g.
`f.integrate(algorithm="mathematica_free")` - that is to say, maybe it
should be `algorithm` instead of `alg`. Maybe even specifically check the
args? I don't know.
The reason I went with alg, was that for alg="gsl", algorithm is one of
the keywords already being used.
>
> The private function `_numerical_integral` needs documentation.
added
>
> {{{
> #This is so the old numerical_integral will still work
> }}}
> is not quite accurate, as it's doing more than that :)
>
> I'm not sure whether the Mma or sympy ones actually will return
numerical values. Also, one should doctest all those options.
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.
Sympy, however does return numerical values for symbolic functions with
closed form.
Added doctest for all algorithms
>
> What is the idea with calling the other numerical integral (from Maxima)
`_nintegral_sym`, since it's not symbolic? Maybe I'm missing something.
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)
>
> I think you now have `Note that in exotic cases` twice in the same
docstring - is that correct?
>
This was already there, I will read the documentation for that function
and see if it is still needed.
> Anyway, all doable things, and the final produce will be quite valuable.
>
> (As a final comment, it would be worth seeing whether the issues at
[http://ask.sagemath.org/question/95/numerical-integration-in-a-function
this discussion] are solved with this ticket. I don't believe so - since
these integrals aren't made symbolic - but it's worth checking.)
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.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7763#comment:20>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
