[SciPy-Dev] Code review for trapz update

Ian Henriksen insertinterestingnamehere at gmail.com
Tue Mar 10 15:32:16 EDT 2015


On Tue, Mar 10, 2015 at 11:30 AM Eric Moore <ewm at redtetrahedron.org> wrote:

>
>
>> This data should integrate to negative "area":
>> x = [1,  2,  3,  4,  5]
>> y = [0, -1, -2, -1,  0]
>> (-4)
>>
>>
> Yes.
>
>
>> This data should integrate to positive "area", even though the x data is
>> decreasing (and we have negative intervals):
>> x = [5, 4, 3, 2, 1]
>> y = [2, 2, 2, 2, 2]
>> (currently, get -8, but should get +8).
>
>
> No. In general the path one integrates over matters.  If you want to think
> about intervals they must be signed.
>
>
>>
>> It might seem reasonable to require a user to always make their x
>> sequence monotonically increasing.  However, trapz is silent if this is
>> not the case, and at the very least should be modified throw an error
>> for non monotonically increasing x sequences.
>>
>>
> Erroring in this case is probably fine.
>

Sorting or checking for sorting isn't a good option.
As a toy example, consider evaluating the residue of 1/z at the origin
using a contour integral.

import numpy as np
t = np.linspace(0, 2 * np.pi, 100)
circ = np.exp(1.0j * t)
reciprocals = 1. / circ
np.trapz(reciprocals, circ) / (2.0j * np.pi)

As it is right now, this (correctly) returns an answer very close to 1.
The output is garbage if the integral is evaluated in sorted form.

-Ian Henriksen


>
>
>> This issue arises, for example, in the conversion of spectral quantities
>> from wavenumber (units of inverse length) to wavelength (units of
>> length).  When the spectral quantity is inverted, a monotonically
>> increasing sequence becomes a monotonically decreasing sequence, and
>> vice versa.  This gives the unexpected result that trapz(<quantity>,
>> <spectrum>) works as expected before conversion, but returns values with
>> the wrong sign after conversion.
>
>
>  I understand why this seems wrong, but the fact that you have to reverse
> the order is actually correct.
>
>>
>>
> This behavior is even more difficult to recognize if the <quantity> (y-
>> value) term is not strictly positive, and a user may utilize trapz
>> incorrectly with no indication that it is not behaving as expected.
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150310/2ff1c605/attachment.html>


More information about the SciPy-Dev mailing list