<p dir="ltr">On May 9, 2015 10:48 AM, "Jaime Fernández del Río" <<a href="mailto:jaime.frio@gmail.com">jaime.frio@gmail.com</a>> wrote:<br>
><br>
> There is a reported bug (issue #5837) regarding different returns from np.nonzero with 1-D vs higher dimensional arrays. A full summary of the differences can be seen from the following output:<br>
><br>
> >>> class C(np.ndarray): pass<br>
> ... <br>
> >>> a = np.arange(6).view(C)<br>
> >>> b = np.arange(6).reshape(2, 3).view(C)<br>
> >>> anz = a.nonzero()<br>
> >>> bnz = b.nonzero()<br>
><br>
> >>> type(anz[0])<br>
> <type 'numpy.ndarray'><br>
> >>> anz[0].flags<br>
>   C_CONTIGUOUS : True<br>
>   F_CONTIGUOUS : True<br>
>   OWNDATA : True<br>
>   WRITEABLE : True<br>
>   ALIGNED : True<br>
>   UPDATEIFCOPY : False<br>
> >>> anz[0].base<br>
><br>
> >>> type(bnz[0])<br>
> <class '__main__.C'><br>
> >>> bnz[0].flags<br>
>   C_CONTIGUOUS : False<br>
>   F_CONTIGUOUS : False<br>
>   OWNDATA : False<br>
>   WRITEABLE : False<br>
>   ALIGNED : True<br>
>   UPDATEIFCOPY : False<br>
> >>> bnz[0].base<br>
> array([[0, 1],<br>
>        [0, 2],<br>
>        [1, 0],<br>
>        [1, 1],<br>
>        [1, 2]])<br>
><br>
> The original bug report was only concerned with the non-writeability of higher dimensional array returns, but there are more differences: 1-D always returns an ndarray that owns its memory and is writeable, but higher dimensional arrays return views, of the type of the original array, that are non-writeable.<br>
><br>
> I have a branch that attempts to fix this by making both 1-D and n-D arrays:<br>
> return a view, never the base array,</p>
<p dir="ltr">This doesn't matter, does it? "View" isn't a thing, only "view of" is meaningful. And in this case, none of the returned arrays share any memory with any other arrays that the user has access to... so whether they were created as a view or not should be an implementation detail that's transparent to the user?</p>
<p dir="ltr">> return an ndarray, never a subclass, and<br>
> return a writeable view.<br>
> I guess the most controversial choice is #2, and in fact making that change breaks a few tests. I nevertheless think that all of the index returning functions (nonzero, argsort, argmin, argmax, argpartition) should always return a bare ndarray, not a subclass. I'd be happy to be corrected, but I can't think of any situation in which preserving the subclass would be needed for these functions.</p>
<p dir="ltr">I also can't see any logical reason why the return type of these functions has anything to do with the type of the inputs. You can index me with my phone number but my phone number is not a person. OTOH logic and ndarray subclassing don't have much to do with each other; the practical effect is probably more important. Looking at the subclasses I know about (masked arrays, np.matrix, and astropy quantities), though, I also can't see much benefit in copying the subclass of the input, and the fact that we were never consistent about this suggests that people probably aren't depending on it too much.</p>
<p dir="ltr">So in summary my feeling is: +1 to making then writable, no objection to the view thing (though I don't see how it matters), and provisional +1 to consistently returning ndarray (to be revised if the people who use the subclassing functionality disagree).</p>
<p dir="ltr">-n</p>