-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Table with generalized columns #1835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Note: may be better to not have column be able to __add__, etc., at all
|
This is a repeat from #1833 but I'll put in in this thread for the record. Basically my view on any fundamental changes to Table is that they satisfy:
Even though |
|
Agreed that |
|
This will be cosed by #3011 - adding labels just so it doesn't show up as no-label any more. |
Triggered by #1833, I thought I would also put the implementation @wkerzendorf and I have been working on for making generalized columns, which can hold any type of array. This is by no means finished, but as our approach is quite different, I thought it was useful to put it out there.
In the
Columnclass, the addition to properly supportQuantityand its sub-classes is remarkably trivial; one just needs to keep track of the few attributes that are needed beyond just the__class__(_unitforQuantity; also_wrap_angleforLongitude; can just get these from__dict__).For things other than
ndarraysubclasses, the main concept is that anything can become a column as long as it can turn itself into a properly sequenced array. We tried only forTimewhere one turns either justjd1, jd2into a 2-item array (to be made structured), and stores all relevant attributes in a dictionary (e.g.,lon,lat). If any of the attributes are also arrays, they get stored in the full array as well (e.g.,delta_ut1_utc1, or indeedlonandlat). The class can take aTimeview of this by lettingjd1, etc., point to the appropriate parts of the combined array.Note that in this implementation,
Columnno longer is a subclass ofndarrayitself; it seemed essentially impossible to have it be that, and have things likenp.sum(table['q'])return aQuantityif the corresponding column holds aQuantity. One advantage is that this holds the promise of just storing aMaskedArrayin aColumn, thus obliviating the need forMaskedColumn, or indeed having whole tables be masked when really only a single column needs to be.Anyway, maybe best to give an example of what's possible now (ignoring that many test cases are now broken...):