Skip to content

Trial: Table Column subclassed from quantity #1583

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.

Sign up for GitHub

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

Jump to bottom
Closed
mhvk wants to merge 4 commits into from
Closed

Trial: Table Column subclassed from quantity #1583

mhvk wants to merge 4 commits into from

Conversation

@mhvk
Copy link
Contributor

@mhvk mhvk commented Oct 15, 2013

While looking again at #1540, I realised that to have table columns behave like quantities, it is not good enough to just add some methods, as, e.g., c.mean() should produce a quantity, not just a number. One more complete solution is to subclass. Fortunately, with super this is surprisingly easy, as shown in this PR. Note especially the lovely definition

class QuantityColumn(Column, Quantity):
    pass

Some notes:

  • This also includes Units-quantity interaction simplification #1558 as well as an unfinished but mostly working MaskedQuantity implementation.
  • For now, it is mostly to open this for comments, as some parts do not yet work (e.g., table.join, etc.).
  • The API has an oddity in that assignment to unit only changes the nature of the Column if it is already part of a Table (where I use _rebuild_table_column_views). I don't know how to handle a column by itself.
  • Also unclear is what should be done upon repeat assignment to unit (Quantities should allow in-place change to compatible units #1253 rears its head!).
  • I'm not completely sure how useful the non-Quantity Column still will be; for numerical cases, a QuantityColumn with unit='' would always seem more appropriate.

Anyway, for now it is fun being able to do things like

In [1]: from astropy.table import Table; import astropy.units as u; import numpy as np

In [2]: t = Table([[1.,2., 3.],[4., 5., 6.]], names=('a','b'))

In [3]: t['a'].unit = 'rad'

In [4]: t['a'].to(u.deg)
Out[4]: <Quantity [  57.29577951, 114.59155903, 171.88733854] deg>

In [5]: t['a']**2
Out[5]: <Quantity [ 1., 4., 9.] rad2>

In [6]: np.cos(t['a'])
Out[6]: <Quantity [ 0.54030231,-0.41614684,-0.9899925 ] >

In [7]: t['a']/u.s
Out[7]: <Quantity [ 1., 2., 3.] rad / s>

In [8]: t['c'] = t['a']/u.s

In [9]: t.columns['c']
Out[13]: 
<QuantityColumn name='c' unit='rad / s' format=None description=None>
array([ 1.,  2.,  3.])

@taldcroft
Copy link
Member

taldcroft commented Oct 15, 2013

@mhvk - Wow, nice to see the exploratory PR! I had spent an hour mucking about in the same direction but didn't get this far. We both ran into the same issue of non-numeric Columns. I wonder if there is any fundamental reason that Quantity cannot support non-numeric values with a requirement that there be no unit (dimensionless_unscaled? or whatever that is).

@embray
Copy link
Member

embray commented Oct 15, 2013

I'd probably rather that QuantityColumns were only used for numeric columns, and not try to chunk on even more functionality to get it to work on strings--I think that's asking for trouble.

Given that QuantityColumn is a subclass of Column there's no reason a table can't have a mix of both. You could even modify the __repr__ so it just shows as Column if that were desirable.

@mhvk
Copy link
Contributor Author

mhvk commented Oct 15, 2013

@taldcroft - interesting thought. Although I share some of @embray's reservations, I'll still look at Quantity in a bit more detail to see where/whether that would break.

A possible advantage still would be that Column and Quantity become nearly identical. It might also help with having Time and Coordinate columns, as those then properly could become "different-view" columns with QuantityColumns underneath. For Time, these would of course hold jd1, jd2 -- indeed, this might make even more sense if we do something I earlier wondered about in #1431 -- whether it would make sense for jd1 and jd2 to be quantities with units of day.

@mhvk mhvk mentioned this pull request Nov 1, 2013
Closed
@astrofrog astrofrog mentioned this pull request Nov 16, 2013
Closed
24 tasks
@mhvk mhvk mentioned this pull request Nov 29, 2013
Closed
@mhvk
Copy link
Contributor Author

mhvk commented Nov 29, 2013

closing this in favour of the more general #1839.

@mhvk mhvk closed this Nov 29, 2013
@astrofrog astrofrog mentioned this pull request Dec 1, 2013
Closed
@mhvk mhvk mentioned this pull request Jan 30, 2014
Closed
@mhvk mhvk deleted the table-subclassed-from-quantity branch June 5, 2015 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@mhvk @taldcroft @embray