[Numpy-discussion] Bug in np.nonzero / Should index returning functions return ndarray subclasses?
njs at pobox.com
Sat May 9 16:03:07 EDT 2015
On May 9, 2015 12:54 PM, "Benjamin Root" <ben.root at ou.edu> wrote:
> Absolutely, it should be writable. As for subclassing, that might be
messy. Consider the following:
> inds = np.where(data > 5)
> In that case, I'd expect a normal, bog-standard ndarray because that is
what you use for indexing (although pandas might have a good argument for
having it return one of their special indexing types if "data" was a pandas
Pandas doesn't subclass ndarray (anymore), so they're irrelevant to this
particular discussion :-). Of course they're an argument for having a
cleaner more general way of allowing non-ndarray array-like objects, but
the legacy subclassing system will never be that.
> foobar = np.where(data > 5, 1, 2)
> Again, I'd expect a normal, bog-standard ndarray because the scalar
elements are very simple. This question gets very complicated when
considering array arguments. Consider:
> merged_data = np.where(data > 5, data, data2)
> So, what should "merged_data" be? If both "data" and "data2" are the same
types, then it would be reasonable to return the same type, if possible.
But what if they aren't the same? Maybe use array_priority to determine the
return type? Or, perhaps it does make sense to say "sod it all" and always
return an ndarray?
Not sure what this has to do with Jaime's post about nonzero? There is
indeed a potential question about what 3-argument where() should do with
subclasses, but that's effectively a different operation entirely and to
discuss it we'd need to know things like what it historically has done and
why that was causing problems.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion