Yet another example is
```
d = np.zeros(n)
d[1:] = np.linalg.norm(np.diff(points, axis=1), axis=0)
r = d.cumsum()
```
https://github.com/WarrenWeckesser/ufunclab/blob/main/examples/linear_interp1d_demo.py#L13-L15
___
NumPy-Discussion mailing list -- numpy
I don’t have an issue with cumsum0 if it is approached as a request for a
useful utility function.
But arguing that this is what a cumulative sum function should be doing is a
very big stretch. Cumulative sum has its foundational meaning and purpose which
is clearly reflected in its name, which
`cumsum` provides a sequence of partial sums, exactly as expected.
https://reference.wolfram.com/language/ref/Accumulate.html
https://www.mathworks.com/help/matlab/ref/cumsum.html
https://docs.julialang.org/en/v1/base/arrays/#Base.cumsum
https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-
Dom Grigonis wrote:
> 1. Dimension length stays constant, while cumusm0 extends length to n+1, then
> np.diff, truncates it back. This adds extra complexity, while things are very
> convenient to work with when dimension length stays constant throughout the
> code.
For n values there are n-1 di
Dear all,another aspect to think about is that there is not only cumsum. There are other cumulative aggregations as well (whether or not they have top-level np functions, like cummax is represented by np.maximum.accumulate):1. cumprod: there instead of starting with zero one would need to start wit
Unfortunately, I don’t have a good answer.
For now, I can only tell you what I think might benefit from improvement.
1. Verbosity. I appreciate that bracket syntax such as one in julia or matlab
`[A B C ...]` is not possible, so functional is the only option. E.g. julia has
functions named ‘cat
I think ultimately the copy is unnecessary.
That being said introducing prepend and append functions concentrates the
complexity of the mapping in one place. Trying to avoid the extra copy would
probably lead to a more complex implementation of accumulate.
How would in your view the prepend i
Note that this is independent from the memory waste. There are way worse
memory ops in NumPy than this so I don't think that argument applies here
even if it was.
And like I mentioned, this is a very common operation hence internals are
secondary. But it is not an unnecessary copy of the array any
On Fri, Aug 18, 2023 at 4:59 AM Ronald van Elburg <
r.a.j.van.elb...@hetnet.nl> wrote:
> I was trying to get a feel for how often the work around occurs. I found
> three clear examples in Scipy and one unclear case. One case in holoviews.
> Two in numpy. One from soundappraisal's code base.
>
See
> Whether it's necessary to have other keywords to prepend anything other
> than zero, or append rather than prepend, is a lot less clear. Did you find
> a clear need for those things?
No, I haven't found them. For streaming data there might be usecases for
starting with an initial offset, but I
On Fri, Aug 18, 2023 at 10:59 AM Ronald van Elburg <
r.a.j.van.elb...@hetnet.nl> wrote:
> I was trying to get a feel for how often the work around occurs. I found
> three clear examples in Scipy and one unclear case. One case in holoviews.
> Two in numpy. One from soundappraisal's code base.
>
Th
I was trying to get a feel for how often the work around occurs. I found three
clear examples in Scipy and one unclear case. One case in holoviews. Two in
numpy. One from soundappraisal's code base.
Next to prepending to the output, I also see prepending to the input as a
workaround.
Some exam
Ilhan Polat wrote:
> I think all these point to the missing convenient functionality that
> extends arrays. In matlab "[0 arr 10]" nicely extends the array to a new
> one but in NumPy you need to punch quite some code and some courage to
> remember whether it is hstack or vstack or concat or block
With this I agree, this sounds like a more radical (in a good way) solution.
> So I think this is a feature request of "prepend", "append" in a convenient
> fashion not to ufuncs but to ndarray. Because concatenation is just pain in
> NumPy and ubiquitous operation all around. Hence probably we
> On 14 Aug 2023, at 15:22, john.daw...@camlingroup.com wrote:
>
>> From my point of view, such function is a bit of a corner-case to be added
>> to numpy. And it doesn’t justify it’s naming anymore. It is not one
>> operation anymore. It is a cumsum and prepending 0. And it is very difficult
On Tue, Aug 15, 2023 at 2:44 PM wrote:
> > From my point of view, such function is a bit of a corner-case to be
> added to numpy. And it doesn’t justify it’s naming anymore. It is not one
> operation anymore. It is a cumsum and prepending 0. And it is very
> difficult to argue why prepending 0 to
> From my point of view, such function is a bit of a corner-case to be added to
> numpy. And it doesn’t justify it’s naming anymore. It is not one operation
> anymore. It is a cumsum and prepending 0. And it is very difficult to argue
> why prepending 0 to cumsum is a part of cumsum.
That is ba
From my point of view, such function is a bit of a corner-case to be added to
numpy. And it doesn’t justify it’s naming anymore. It is not one operation
anymore. It is a cumsum and prepending 0. And it is very difficult to argue why
prepending 0 to cumsum is a part of cumsum.
What I would rath
On Fri, 2023-08-11 at 13:43 -0400, Benjamin Root wrote:
> I'm really confused. Summing from zero should be what cumsum() does
> now.
>
What they mean is *including* the "implicit" 0 in the result. There
are some old NumPy issues on this, suggesting something like a new
kwarg like `include_initia
On 11 Aug 2023, at 7:52 pm, Robert Kern
mailto:robert.k...@gmail.com>> wrote:
>>> np.cumsum([[1, 2, 3], [4, 5, 6]])
array([ 1, 3, 6, 10, 15, 21])
```
which matches your example in the cumsum0() documentation. Did something change
in a recent release?
That's not what's in his example.
The exa
This has come up before, see https://github.com/numpy/numpy/issues/6044 for
the first time this came up; there were several subsequent discussions
linked there.
In the meantime, the data APIs consortium has been actively working on
adding a `cumulative_sum` function to the array API standard, see
After blinking and rubbing my eyes, I finally see what is meant by all of
this. I see now that the difference is that `cumsum0()` would return a
result that essentially have 0 be prepended to what would normally be the
result from `cumsum()`. From the description, I thought the "problem" was
that t
On Fri, Aug 11, 2023 at 1:47 PM Benjamin Root wrote:
> I'm really confused. Summing from zero should be what cumsum() does now.
>
> ```
> >>> np.__version__
> '1.22.4'
> >>> np.cumsum([[1, 2, 3], [4, 5, 6]])
> array([ 1, 3, 6, 10, 15, 21])
> ```
> which matches your example in the cumsum0() doc
I'm really confused. Summing from zero should be what cumsum() does now.
```
>>> np.__version__
'1.22.4'
>>> np.cumsum([[1, 2, 3], [4, 5, 6]])
array([ 1, 3, 6, 10, 15, 21])
```
which matches your example in the cumsum0() documentation. Did something
change in a recent release?
Ben Root
On Fri,
I'm very sensitive to the issues of adding to the already bloated numpy API,
but I would definitely find use in this function. I literally made this error
(thinking that the first element of cumsum should be 0) just a couple of days
ago! What are the plans for the "extended" NumPy API after 2.0?
25 matches
Mail list logo
