[SciPy-Dev] Discussion on a new interface for multidimensional quadrature

Ralf Gommers ralf.gommers@gmail....
Tue Aug 13 15:07:57 CDT 2013

```On Tue, Aug 13, 2013 at 9:49 PM, Nathan Woods <charlesnwoods@gmail.com>wrote:

> 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*, *
>
> 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