Repository navigation
ndarray-like base class #4096
Description
Although I don't recall exactly what the reasons were, I believe for good reasons the Time class does not subclass numpy.ndarray. Nevertheless, array-like Time objects behave a lot like ndarray in that indexing works as one would expect with an ndarray, and it implements all of the ndarray methods.
The SkyCoord class also does not subclass ndarray for good reasons, but supports similar indexing operations for arrays of coordinates. Unlike Time, it does not support ndarray-like methods. But I feel like it would be good if, so long as we're offering array-like special objects, we should strive to emulate the ndarray interface as consistently as possible with those objects (as we also do with Quantity, which of course is an ndarray subclass). I think not all such methods and attributes are always applicable, but I think this should be a general goal at least. It would be consistent and represent the least astonishment to users.
That's why I'm suggesting a base class that provides stubs for many applicable ndarray attributes and methods. Time and SkyCoord (and any other applicable classes--I'm thinking Model as well) can use this class as a mixin and implement only those interfaces that make sense for the class. To an extent this can be made pretty automatic too--Time has a generic method that knows how to represent a Time as a couple of bare ndarrays, apply the ndarray methods directly, and then reconstitute the result as a Time. So most ndarray methods can be implemented just by implementing a general method(s) for to-from ndarray.
One thing Time is currently missing, which we should also have, is some equivalent of np.concatenate that works with non-ndarrays. Not sure yet exactly how I see that working--maybe as a classmethod.
Activity
mhvk commentedon Aug 28, 2015
@embray - yes, I think this is a very good idea. As you say, in
Time, it turned out that all that was really needed was a way to apply the method to the underlying jd1 and jd1 ndarrays, and then recombining them in a newTimeinstance. I think it should be quite easy to do the same forSkyCoord.taldcroft commentedon Sep 1, 2015
I guess my question is how extensive the list of stubs would be. Specifically I'm thinking of
SkyCoordwhere there is no concept of ordering so that all the min / max / sort-based methods would not be implemented.I can see this being a useful way to provide all the shape-changing methods where (at least in the Time example) it's clear that there is a pattern that could be factored out.
mhvk commentedon Sep 1, 2015
It would seem a generalized method that does shape-changing and different views (
__getitem__) would make sense as a start. Those are also the ones inTimethat do little more than callself._replicate(method, *args, **kwargs), so exactly the ones for which it makes sense to factor it out.embray commentedon Sep 1, 2015
I mean, one could come up with an ordering for
SkyCoord, right? It just wouldn't be that useful.taldcroft commentedon Sep 2, 2015
I don't think it would be a good thing to add methods that we know are not useful.
mhvk commentedon Sep 3, 2015
See #4123 for an initial trial for just the indexing/shape-changing methods.
mhvk commentedon Nov 2, 2015
Done for
Time-- forSkyCoord, see #4123mhvk commentedon Nov 18, 2016
Closing since we now do have
ShapedLikeNDArrayand it seems to work well!