> Assuming totally normal numpy arrays, the former will first produce a boolean
> array of size N, then a second boolean array of size N to have the negated
> values. Meanwhile, no such extra arrays are made for the latter case. So, you
> are asking users to move to a potentially less performant
> whether it is the data that should indicate what needs to be skipped, or
> should the algorithm dictate that?
Can you clarify what exactly you mean by "the data" and "the algorithm" here?
___
NumPy-Discussion mailing list -- [email protected]
One thing that should be pointed out is that there is a subtle
difference between calling
`np.mean(x, where=~np.isnan(x))`
and
`np.nanmean(x)`
Assuming totally normal numpy arrays, the former will first produce a
boolean array of size N, then a second boolean array of size N to have
the negated
Another, perhaps more radical, possibility is to remove special handling for
nans from NumPy entirely. More precisely:
1. Add a `where` argument to all normal counterparts of nan-ignoring functions
that are currently missing it (see https://github.com/numpy/numpy/issues/26336).
2. Add a short FA
FWIW, [pandas](https://pandas.pydata.org/docs/) also has a `skipna` argument
for
[reductions](https://pandas.pydata.org/docs/reference/api/pandas.api.extensions.ExtensionArray._reduce.html)
and
[accumulations](https://pandas.pydata.org/docs/reference/api/pandas.api.extensions.ExtensionArray._ac
nanmean internally calls mean, sum, and count. Folding the functionality under
mean itself would reduce complexity and the total amount of code, not increase
it.
___
NumPy-Discussion mailing list -- [email protected]
To unsubscribe send an ema
On Thu, Oct 2, 2025 at 6:27 PM Oscar Benjamin
wrote:
> On Tue, 9 Sept 2025 at 20:15, Ralf Gommers via NumPy-Discussion
> wrote:
> >
> > GitHub Actions has deprecated the macos-13 image [1], which was the last
> image to support Intel x86-64 runners. As a result, we won't be able to use
> our cur
This is getting into implementation details, but...
> My suggestion of a nan-as-omit Array API compatible wrapper class would
> need them, and so would extending nanfunctions to cover more cases.
> Indeed, it would even help the keyword-argument case as it would provide
> working implementatio
On Thu, Oct 23, 2025 at 2:18 PM Marten van Kerkwijk via NumPy-Discussion <
[email protected]> wrote:
> Hi Ralf,
>
> > So I think the relevant choices are:
> > 1. Change nothing to the current status quo (and possibly direct end
> users who need more than
> > what we offer now to `marray`
Hi Ralf,
> So I think the relevant choices are:
> 1. Change nothing to the current status quo (and possibly direct end users
> who need more than
> what we offer now to `marray`)
> 2. Add a keyword to reductions
> 3. Add a single factory function that turns regular reductions into nan-aware
> on
On Wed, Oct 22, 2025 at 10:48 PM Marten van Kerkwijk via NumPy-Discussion <
[email protected]> wrote:
> Hi Carlos,
>
> Indeed, the implementation for making NaN mean "omit" for some functions
> is not too difficult now. Your example actually leads to the opposite
> conclusion about ease
11 matches
Mail list logo
