<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 5:55 AM, Evgeni Burovski <span dir="ltr">&lt;<a href="mailto:evgeny.burovskiy@gmail.com" target="_blank">evgeny.burovskiy@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>How about adding an optional argument to nquad, specifying the order of integration limits? Defaulting to the &#39;forward&#39; order. Something like</p>

<p>nquad(f(x,y), [a, b], [g(x), h(x)])<br>
being the default, and</p>
<p>nquad(f(x,y), [a, b], [g(y), h(y)], integration_order=&#39;reversed&#39;)<br>
interpreting the limits the way dblquad/tplquad do.</p></blockquote><div><br></div><div>That makes sense to me, both to make it easier to map to dblquad/tplquad and to avoid writing an argument-reversing wrapper when you want to integrate an existing function.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
<p>Evgeni</p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Aug 9, 2013 11:35 AM, &quot;Nathan Woods&quot; &lt;<a href="mailto:charlesnwoods@gmail.com" target="_blank">charlesnwoods@gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Clear documentation is always important, so I don&#39;t think there will be any problems there. Does anyone else have thoughts they&#39;d like to share?<br>
<br>
Nate<br>
<br>
On Aug 5, 2013, at 11:35 PM, <a href="mailto:josef.pktd@gmail.com" target="_blank">josef.pktd@gmail.com</a> wrote:<br>
<br>
&gt; On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers &lt;<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods &lt;<a href="mailto:charlesnwoods@gmail.com" target="_blank">charlesnwoods@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I&#39;m copying the most relevant parts over from a discussion on GitHub,<br>
&gt;&gt;&gt; having to do with a new n-dimensional integration tool. The discussion is<br>
&gt;&gt;&gt; whether or not to make nquad&#39;s new interface consistent with dbl-and<br>
&gt;&gt;&gt; tplquad, even though their precedent is arguably more confusing to users.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; nquad is a recursively defined wrapper to scipy.integrate.quad that allows<br>
&gt;&gt;&gt; for n-dimensional integration with almost the entire list of arguments<br>
&gt;&gt;&gt; allowed by quad. It is therefore more general than either dbl- or tplquad,<br>
&gt;&gt;&gt; and encompasses their use cases, while allowing the user greater control<br>
&gt;&gt;&gt; over the integration. The interface is given: nquad( f(x0,x1,…xn,t0,…tm)<br>
&gt;&gt;&gt; ,[[x0_lo,x0_hi],…[xn_lo,xn_hi]],[t0,…tm],[opts0,…optsn]).<br>
&gt;&gt;&gt; The ranges of integration are given in the same order as the arguments in<br>
&gt;&gt;&gt; the function to be integrated. This ordering is consistent with both Matlab<br>
&gt;&gt;&gt; and Octave, and it is similar to what is encountered in other SciPy packages<br>
&gt;&gt;&gt; such as fft. It is also what makes sense to new users.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; dbl- and tplquad, however, reverse the order of arguments in f. From the<br>
&gt;&gt;&gt; documentation for tplquad:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Return the triple integral of func(z, y, x) from x=a..b,<br>
&gt;&gt;&gt; y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This is confusing, and contrary to common practice.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It is proposed that nquad&#39;s calling sequence be left as is, and that the<br>
&gt;&gt;&gt; use of dbl- and tplquad be deprecated in some future version of SciPy, and<br>
&gt;&gt;&gt; that nquad be recommended for multidimensional integration in new code. dbl-<br>
&gt;&gt;&gt; and tplquad would of course be retained, though not recommended, in order to<br>
&gt;&gt;&gt; avoid breaking existing code.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Wow, that came out all legalistic. Anyway, what do you all think about<br>
&gt;&gt;&gt; this change? I have a horse in the race (I wrote most of nquad), but I<br>
&gt;&gt;&gt; really think that maintaining the backwards style from dbl- and tplquad and<br>
&gt;&gt;&gt; enshrining it in new code is a bad idea. This is a perfect time to get away<br>
&gt;&gt;&gt; from it, if that&#39;s what we want to do.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; My first instinct was that nquad should match what&#39;s already there in<br>
&gt;&gt; scipy.integrate, but I&#39;ve changed my mind. I always have to look at the<br>
&gt;&gt; dblquad/tplquad documentation to get it right, so those functions don&#39;t have<br>
&gt;&gt; a good API imho. Therefore just making nquad do the logical thing (i.e.<br>
&gt;&gt; ``f(x, y ,z)``) makes sense to me.<br>
&gt;&gt;<br>
&gt;&gt; Let&#39;s not use the word &quot;deprecate&quot; for dblquad/tplquad, since they shouldn&#39;t<br>
&gt;&gt; be removed. Instead just recommend `nquad` as the function to use in the<br>
&gt;&gt; docs.<br>
&gt;&gt;<br>
&gt;&gt; Any other opinions?<br>
&gt;<br>
&gt; How do you know the integration order in the new interface?<br>
&gt;<br>
&gt; The current dblquad, tplquad looks to me like writing an integral<br>
&gt;<br>
&gt; integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz<br>
&gt; where integration limits are x=a..b, y=gfun(x)..hfun(x), and<br>
&gt; z=qfun(x,y)..rfun(x,y)<br>
&gt;<br>
&gt; based on reading of the docstrings for tplquad. So this doesn&#39;t look<br>
&gt; very strange to me.<br></blockquote></div></div></div></blockquote><div><br></div><div>I guess that was the reason why dblquad/tplquad are implemented the way they are. The problem with that is that no one writes functions like f(z, y, x), everyone writes f(x, y, z). So it&#39;s plain unnatural.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

&gt;<br>
&gt; The suggested description<br>
&gt; ``<br>
&gt; The interface is given: nquad( f(x0,x1,…xn,t0,…tm)<br>
&gt; ,[[x0_lo,x0_hi],…[xn_lo,xn_hi]],[t0,…tm],[opts0,…optsn]).<br>
&gt; The ranges of integration are given in the same order as the arguments<br>
&gt; in the function to be integrated. </blockquote></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; ```<br>
&gt;<br>
&gt; Does this mean we integrate over x0 first (innermost integral) or last<br>
&gt; (outermost integral) ?<br></blockquote></div></div></div></blockquote><div><br></div><div>x0 first, that should be made clearer in the docstring.<br><br></div><div>Ralf<br><br></div></div></div></div>