On So, 2016-09-04 at 11:20 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > I haven't given this as much thought as it deserves, but thought I > would comment from the astropy perspective, where we both have direct > subclasses of `ndarray` (`Quantity`, `Column`, `MaskedColumn`) and > classes that store their data internally as ndarray (subclass) > instances (`Time`, `SkyCoord`, ...). > > One comment would be that if one were to introduce a special method, > one should perhaps think a bit more broadly, and capture more than > the > indexing methods with it. I wonder about this because for the > array-holding classes mentioned above, we initially just had > `__getitem__`, which got the relevant items from the underlying > arrays, and then constructed a new instance with those. But recently > we realised that methods like `reshape`, `transpose`, etc., require > essentially the same steps, and so we constructed a new > `ShapedLikeNDArray` mixin, which provides all of those [1] as long as > one defines a single `_apply` method. (Indeed, it turns out that the > same technique works without any real change for some numpy functions > such as `np.broadcast_to`.) > > That said, in the actual ndarray subclasses, we have not found a need > to overwrite any of the reshaping methods, since those methods are > all > handled OK via `__array_finalize__`. We do overwrite `__getitem__` > (and `item`) as we need to take care of scalars. And we would > obviously have to overwrite `oindex`, etc., as well, for the same > reason, so in that respect a common method might be useful. > > However, perhaps it is worth considering that the only reason we need > to overwrite them in the first place, unlike what is the case for all > the shape-changing methods, is that scalar output does not get put > through `__array_finalize__`. Might it be an idea to have the new > indexing methods return array scalars instead of normal ones so we > can > get rid of this?
I did not realize the new numpys are special with the scalar handling? The indexing (already before 1.9. I believe) always goes through PyArray_ScalarReturn or so, which I thought was used by almost all functions. If you mean the attributes (oindex, etc.), they could behave a bit different of course, though not sure to what it extend it actually helps since that would also create disparity. If we implement a new special method (__numpy_getitem__), they definitely should behave slightly different in some places. One option might be to not even do the wrapping, but leave it to the subclass. However, if you have an array with arrays inside, knowing whether to return a scalar correctly would have to rely on inspecting the index object, which is why I suggested the indexer to give a few extra informations (such as this one). Of course, since the scalar return goes through a ScalarReturn function, that function could maybe also be tought to indicate the scalar to `__array_finalize__`/`__array_wrap__` (not sure what exactly applies). - Sebastian > All the best, > > Marten > > [1] https://github.com/astropy/astropy/blob/master/astropy/utils/misc > .py#L856 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
