[SciPy-Dev] Discussion on a new interface for multidimensional quadrature
Wed Aug 14 06:54:12 CDT 2013
On Aug 13, 2013 9:08 PM, "Ralf Gommers" <firstname.lastname@example.org> wrote:
> On Tue, Aug 13, 2013 at 9:49 PM, Nathan Woods <email@example.com>
>> Right, that's what I thought, too. The thing is that dbl- and tplquad
DON'T do that. If you carefully at the calling sequence for tplquad,
>> scipy.integrate.tplquad(func, a, b, gfun, hfun, qfun, rfun, args=(),
>> Return the triple integral of func(z, y, x) from x=a..b,
y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>> The only way that the underlying quad routine can accept qfun(x,y) and
rfun(x,y) as limits is if they are evaluated to be constants. That is,
integration over z must be the innermost loop of integration, with
fund(z,y,z), qfun(x,y), and rfun(x,y) receiving (x,y) passed in as
arguments from the outer loops.
>> I agree that the changes I just put in are kind of ridiculous, but (as
far as I can tell) they exactly duplicate what is done in dbl- and tplquad.
>> If we really want to put in some kind of integration order, then that's
also not too hard, though a bit more than just reversing the lists. It's
just something that I don't see a real, compelling reason to do.
> Agreed, no very compelling reason. What's required would be not that much
more, basically ``lambda x, y, z: func(z, y, x)``, plus *args. I have
written little function wrappers like that before for use with
> Maybe better to leave it out and merge as it was.
Well, my first thought was to allow a user to change, say,
and that would just work.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev