William Stein wrote: > On Tue, Oct 27, 2009 at 2:05 PM, Jason Grout > <jason-s...@creativetrax.com> wrote: >> Writing some class worksheets yesterday exposed me to our >> inconsistencies in numerical integration commands. Currently: >> >> * numerical_integral calls gsl to do integration, and the syntax is >> numerical_integral(f, start, end) or numerical_integral(f, (start, end)). >> >> * if you have a symbolic expression f, then f.nintegrate(var, start, >> end) uses maxima to compute the numerical integral. This returns >> several more arguments than the GSL version above. >> >> * nintegrate/nintegral is not a top-level command >> >> >> Here's a proposal: >> >> * A single top-level command nintegrate/nintegral, which calls the >> object's nintegral method, if it exists; otherwise, convert to SR and >> call the nintegral method. This mirrors the integral top-level command. >> >> * Enhance the SR .nintegral method to have an algorithm option: >> >> - algorithm='gsl' (default) -- call the gsl numerical integration. >> In a simple test of integrating sin(x) from 2 to 4, gsl was about 10 >> times faster than the current algorithm of calling maxima. Also, change >> the gsl command to accept a variable of integration argument, which it >> then uses when constructing the fast_float version of the expression if >> it is symbolic. >> >> - algorithm='scipy' -- call the scipy numerical integration routines >> (maybe make this the default if it is faster than gsl). >> >> - algorithm='maxima' -- use maxima numerical integration >> >> - maybe a sympy option too? > > I like that proposal.... except the parts that will break existing > code. This is incredibly commonly used functionality, so there is > probably a ton of code out there that could be broken if you change > things. At a minimum, the change should be phased in very carefully.
yes, sorry, let's add this: * All current commands continue to work and produce the same answers. In particular, the gsl numerical_integration command *optionally* accepts a variable. * the top-level numerical_integral command has a deprecation warning telling people to switch to the top-level nintegral command (which then uses gsl by default). >> Also, I noticed that we have both "integral" and "integrate" as >> identical top-level commands. What is the purpose? This seems like >> needless clutter. What do people think of deprecating one or the other >> (I suggest keeping "integrate" and deprecating "integral"). > > I would prefer not to do this, since "needless clutter" is not > sufficient justification for removing something that is definitely in > widespread use already. That would be great justification for not > adding it in the first place though. What about nintegrate/nintegral? We don't have these now (as top-level functions), but they would mirror nicely the integral/integrate commands. Should we only define one of them? Thanks, Jason -- Jason Grout --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
