[SciPy-Dev] Code review for trapz update

fizyxnrd fizyxnrd at gmail.com
Tue Mar 10 16:22:08 EDT 2015


Eric Moore <ewm <at> redtetrahedron.org> writes:

> 
> 
> 
> Trapz finds the area under a one-to-one association of y values with x
> values.  If y(x) > 0, then the area bounded by [a, b] between y(x) and
> x=0 should always be positive.  
> 
> You could write a trapz that does that, however np.trapz finds the 
integral from a to b of y using the sampled data you provide.  The 
"from" in there is important.  Since we are integrating samples, the a 
and b are essentially the first and last points of the x input. Since a 
is x[0] and b is x[-1], the x array is defining the path along which to 
integrate. 
> 
>  
> The core property you have referenced
> above is the very property that should be used in order to achieve the
> equivalence with integrating along a negative path.  Maintaining this
> separation preserves the equivalence of
> np.trapz(y,x) == np.trapz(y[::-1], x[::-1]), which I believe is an
> equivalence that should hold true.
> 
> 
> This equivalence is false.  For instance both of these results are 
correct.  Would they still be with your changes?
> In [46]: x = np.exp(1j*np.pi*np.linspace(0,1,100))
> 
> In [47]: z = 1/x
> 
> In [48]: np.trapz(z, x)
> Out[48]: (1.3244509217643717e-18+3.1410654163086975j)
> 
> In [49]: np.trapz(z[::-1], x[::-1])
> Out[49]: (-1.3244509217643594e-18-3.1410654163086971j)

These results would still be correct.  In the first case, the user 
simply specifies that they wish to know $Z(x) - Z(0) = \int_0^x z(x') 
dx'$, while in the second case, they specify that they are looking for 
Z(0) - Z(x) = \int_x^0 z(x') dx' = -\int_0^x z(x') dx'$.
I'm asserting that the two should be completely equivalent, and that the 
user recognize that the endpoints in the first instance are 1 and -1 
($\theta \elem [0, \pi]$), while in the latter case the endpoints are -1 
and 1 ($\theta \elem [\pi, 0]$).  Thus $\int_0^x z(x)$ is given by 
np.trapz(z, x) and $\int_x^0 z(x)$ is given by -np.trapz(z, x).

This modification treats the area under the curve as independent of 
path, and asks the user to use path endpoints to determine what should 
be done with that quantity.

I can certainly understand the argument for the existing position.  I 
only advocate the change because I have never come across a circumstance 
in which I need to use it the way it is, and I and others expect that 
the sign of trapz should only depend on the sign of y, not the order of 
x.


More information about the SciPy-Dev mailing list