cumtrapz does not behave as expected (Trac #1574)

[scipy-gitbot]

Original ticket http://projects.scipy.org/scipy/ticket/1574 on 2011-12-15 by trac user tillahoffmann, assigned to unknown.

The function cumtrapz does not behave as one would expect from the definition of an integral because the length of the output vector is the length of the input vector - 1.

However, if a function is defined on a discrete set of N points then so is the integral.

A 0 should be prepended to the resulting vector.

[scipy-gitbot]

@rgommers wrote on 2011-12-17

I agree with this. It will break backwards compatibility though, so should be discussed on the mailing list first. Could you bring it up on scipy-dev?

The implementation also looks a bit cryptic. A more understandable one would be welcome. As would a better docstring (Returns, Examples). Furthermore it could reference cumsum/cumprod in numpy.

[scipy-gitbot]

@WarrenWeckesser wrote on 2011-12-29

An initial 0 sounds reasonable. To maintain backwards compatibility, a keyword argument, say initial, could be added. If initial=None, the function maintains the current behavior and returns N-1 points in the given axis. Otherwise, the value of initial is the first value of the result, and N points are returned in the given axis. The typical case would be initial=0.

Ultimately, however, it would be nice if initial=0 was the default behavior, so I haven't convinced myself that this would be a good interim solution.

[scipy-gitbot]

@rgommers wrote on 2011-12-29

Using Google Code Search I see that cumtrapz is used quite a bit, and in the code snippets it displays I don't see people prepending a 0 immediately. Therefore my conclusion would be that this is not worth breaking backwards compatibility for. +1 for initial=None.

[scipy-gitbot]

@rgommers wrote on 2012-01-04

Added initial kw in #125, please review it there.

[scipy-gitbot]

Milestone changed to 0.11.0 by @rgommers on 2012-01-04

[scipy-gitbot]

@rgommers wrote on 2012-01-31

Added initial kw in 6eb2da0.