I think the logical choice would be to allow a weighted average in the
nan-functions, not to change `np.average`. In particular, I think it is bad API
to add options for such exclusions; we have another open issue about infinitiy
in the data, which leads to nan even with weight 0 (because
Hi there,
I would love some input on this issue,
https://github.com/numpy/numpy/issues/21375.
I have created a draft PR which I believe resolves it,
https://github.com/numpy/numpy/pull/25474. Decided to go with adding ignore_nan
to np.average rather than adding weights to np.nanmean as it
To me this sounds like a reasonable change.
It does seem like there is a return value which is more sensible than
alternatives.
And the fact that sympy is already doing that indicates that same conclusion
was reached more than once.
I am not dealing much with complex numbers at the moment,
On Sat, 2023-12-23 at 09:56 -0500, Marten van Kerkwijk wrote:
> Hi Sebastian,
>
> > That looks nice, I don't have a clear feeling on the order of
> > items, if
> > we think of it in terms of `(start, stop)` there was also the idea
> > voiced to simply add another name in which case you would
Hi Sebastian,
> That looks nice, I don't have a clear feeling on the order of items, if
> we think of it in terms of `(start, stop)` there was also the idea
> voiced to simply add another name in which case you would allow start
> and stop to be separate arrays.
Yes, one could add another
On Fri, 2023-12-22 at 18:01 -0500, Marten van Kerkwijk wrote:
> Hi Martin,
>
> I agree it is a long-standing issue, and I was reminded of it by your
> comment. I have a draft PR at
> https://github.com/numpy/numpy/pull/25476
> that does not change the old behaviour, but allows you to pass in a
