Re: Initial kw behaviour for cumulative_trapezoid

On Wed, Mar 29, 2023 at 5:26 AM Praveer Nidamaluri <[email protected]> wrote:

> Hello everyone!
>
> `integrate.cumulative_trapezoid` performs a cumulative integration of
> fixed samples. The function provides an `initial` kw that can be used to
> add the starting value for the result. The initial value is just prepended
> to the result array and not summed to the result. I think this is confusing
> and should be updated so that the initial value is prepended to the array
> AND summed to the array.
>
> This was previously discussed in #125, where the concluding thought was:
> "initial is just a mechanism to keep the output and the input the same
> length. This has more to do with the "initial" region (i.e. the area under
> the curve between the non-existent previous value of x and x[0])."
>
> However, cumulative_trapezoid is a cumulative sum of the areas. If we
> prepend the area from the "initial" region, we would necessarily have to
> add it to the sum of the subsequent areas. By prepending the value it is
> now now an initial condition for the integration.
>
> Consider the following practical example:
> -   Let y be sampled velocity data of an oscillating object. We can
> cumulatively integrate to get the displacement of the object. We know the
> starting position (initial value) is 10m. Without the initial value input,
> the displacement data will show oscillations around 0m. With the initial
> value, the displacement should ideally show oscillations around 10m: eg:
> [10, 8, 5, 7, 10, 12, 13, 11, 5, 10]
> -  But, with the cumulative_trapezoid implementation, the first value
> would be 10m, and the object would then be oscillating around 0m, which is
> incorrect, eg:
> [10, -2, -5, -3, 0, 2, 3, 1, -5, 0].
> - This behaviour confused me as a user. It can be fixed by prepending and
> adding the initial value.
>
> Regarding backward compatibility, `initial` would likely be used as
> "initial=None" or "initial=0". The results for cumulative_trapezoid for
> these values of `initial` would be identical even if the proposed update is
> made.
>
> For context, this discussion came up again in #18151 for implementation of
> `initial` in the proposed `cumulative_simpson` function.
>
> What are your thoughts on this?
>

The behavior can't be silently changed to return different numerical
values, but if it helps to restrict the values allowed for `initial` to 0
and None, raising an exception otherwise, that could work. The non-zero
input case can be easily added by the user separately, it'd be a `+=
other_value` one-liner.

Cheers,
Ralf

_______________________________________________
SciPy-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/scipy-dev.python.org/
Member address: [email protected]