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

[Evgeni Burovski]

On Aug 15, 2013 2:54 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
>
> On Aug 14, 2013, at 5:54 AM, Evgeni Burovski <evgeny.burovskiy at gmail.com>
wrote:
>
>>
>> On Aug 13, 2013 9:08 PM, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>> >
>> >
>> >
>> >
>> > On Tue, Aug 13, 2013 at 9:49 PM, Nathan Woods <charlesnwoods at 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, args=(),
epsabs=1.49e-08, epsrel=1.49e-08)[source]¶
>> >>
>> >> 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
dblquad/tplquad.
>> >
>> > Maybe better to leave it out and merge as it was.
>> >
>> > Ralf
>> >
>>
>> Well, my first thought was to allow a user to change, say,
>> tplquad(...whatever...)
>> to
>> nquad(...whatever..., reversed=True),
>> and that would just work.
>>
>> _______________________________________________
>>
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> Unfortunately, the interfaces are different enough that a simple flag
wouldn't be enough. nquad wraps all of the range arguments into nested
lists, where tplquad keeps them all out in the argument list. You would
have to write either some kind of wrapper, or else allow for different
calling sequences with some creative use of *args and **kwargs. Not to
mention, keeping all of the ordering for everything straight would be a
nightmare. Take a look at the function "nquad", if you want to see what I
mean.
https://github.com/thezealite/scipy/blob/master/scipy/integrate/quadpack.py
>
> Mostly, I think that's a bad idea, since it pretty much explodes the
number of ways things can go wrong. I think it's much better to keep things
simple, and just have users learn the new interface if they want the new
functionality (more dimensions, more option control).

Makes perfect sense --- my suggestion is useless.

It might be helpful to users then to have an entry in a tutorial, showing
how to do things both ways. For example, a function of two or three
arguments, integrated over some reasonably simple limits first by
dblquad/tplquad, and then by nquad.

Zhenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130815/040347e0/attachment.html>