You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is something I noticed with looking into #572:
In [1]: from astropy.constants.cgs import e
In [2]: e.unit.decompose()
Out[2]: Unit("3.162278e-05 kg(1/2) m(3/2) / (s)")
This is correct, but I still would have expected:
Out[2]: Unit("g(1/2) cm(3/2) / (s)")
Since the scale on what I get instead is not 1, it seems like this could lead to trouble if one is not careful. I'm not sure how easy this is to fix though.
Not really easy at all -- there's no metadata in the unit about what is cgs vs. si and having that distinction was not part of the original design. I think the easiest way to fix it is to probably not build the cgs units in terms of si ones (have them live in their own universe) and then provide an equivalency mapping that could be used when the user explicitly wants to convert from one to the other (and any syntactic sugar like to_si or to_cgs that we want to build on top).
It does look like there is some sort of smarts about cgs units in the Quanity class. (I hadn't noticed this before). Something like that might help here, but I still think I prefer keeping the universes separate -- seems cleaner and less likely to allow the user to shoot oneself in the foot.
@mdboom, do you think we should actually do that (separate the systems into separate universes)? Definitely not in this release, but perhaps for 0.3? I'm guessing it would be a fair amount of work...
I've spent a little time on this today. Enough to know this should probably not be done for 0.2, and I'm starting to have my doubts about separate universes in general -- you lose a lot of functionality by doing that (it makes it harder for simple and obvious conversions to be performed that need to hope back and forth across the si/cgs divide). Additionally, it's really confusing (I think) to a user that si.cm != cgs.cm, especially when they are logically defined to be the same thing. I think the better way forward is to provide a way to say "decompose to such-and-such system" and make it explicit. But that is going to requiring the long-put-off unit recompose feature to be implemented... stay tuned...
Activity
mdboom commentedon Dec 19, 2012
Not really easy at all -- there's no metadata in the unit about what is cgs vs. si and having that distinction was not part of the original design. I think the easiest way to fix it is to probably not build the cgs units in terms of si ones (have them live in their own universe) and then provide an equivalency mapping that could be used when the user explicitly wants to convert from one to the other (and any syntactic sugar like
to_siorto_cgsthat we want to build on top).mdboom commentedon Dec 19, 2012
It does look like there is some sort of smarts about cgs units in the Quanity class. (I hadn't noticed this before). Something like that might help here, but I still think I prefer keeping the universes separate -- seems cleaner and less likely to allow the user to shoot oneself in the foot.
embray commentedon Dec 19, 2012
Right, I was afraid that was the case, i don't propose we go making big changes to work around this. Just thought it would be worth putting out there.
eteq commentedon Dec 20, 2012
@mdboom, do you think we should actually do that (separate the systems into separate universes)? Definitely not in this release, but perhaps for 0.3? I'm guessing it would be a fair amount of work...
mdboom commentedon Dec 20, 2012
I've spent a little time on this today. Enough to know this should probably not be done for 0.2, and I'm starting to have my doubts about separate universes in general -- you lose a lot of functionality by doing that (it makes it harder for simple and obvious conversions to be performed that need to hope back and forth across the si/cgs divide). Additionally, it's really confusing (I think) to a user that
si.cm != cgs.cm, especially when they are logically defined to be the same thing. I think the better way forward is to provide a way to say "decompose to such-and-such system" and make it explicit. But that is going to requiring the long-put-off unit recompose feature to be implemented... stay tuned...astrofrog commentedon Dec 20, 2012
Maybe
decomposecould take an optional argument,siorcgs, and the latter would implicitly calldecompose().cgs?mdboom commentedon Sep 4, 2013
I think this is at least partially resolved now, since you can do:
but units still don't know what system they are defined in, and I'm still not sure that's a good idea, since many rightfully belong to both.
mdboom commentedon Oct 21, 2013
I'd like to close this -- I think we've found a better solution in the meantime. @embray?
embray commentedon Oct 23, 2013
Yeah, the
basesapproach is a sound resolution to this issue.Merge pull request astropy#576 from WilliamJamieson/jamieson_stepdown