Repository navigation
ndarray-like base class #4096
Description
Activity
@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.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.
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.I mean, one could come up with an ordering for
SkyCoord, right? It just wouldn't be that useful.I don't think it would be a good thing to add methods that we know are not useful.
Closing since we now do have
ShapedLikeNDArrayand it seems to work well!
Although I don't recall exactly what the reasons were, I believe for good reasons the
Timeclass does not subclassnumpy.ndarray. Nevertheless, array-likeTimeobjects behave a lot likendarrayin that indexing works as one would expect with anndarray, and it implements all of thendarraymethods.The
SkyCoordclass also does not subclassndarrayfor good reasons, but supports similar indexing operations for arrays of coordinates. UnlikeTime, it does not supportndarray-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 thendarrayinterface as consistently as possible with those objects (as we also do withQuantity, which of course is anndarraysubclass). 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
ndarrayattributes and methods.TimeandSkyCoord(and any other applicable classes--I'm thinkingModelas 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--Timehas a generic method that knows how to represent aTimeas a couple of barendarrays, apply thendarraymethods directly, and then reconstitute the result as aTime. So mostndarraymethods can be implemented just by implementing a general method(s) for to-fromndarray.One thing
Timeis currently missing, which we should also have, is some equivalent ofnp.concatenatethat works with non-ndarrays. Not sure yet exactly how I see that working--maybe as a classmethod.