Skip to content

Decompose cgs units to other cgs units #576

Closed

Description

@embray

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.

Activity

  1. mdboom commented on Dec 19, 2012

    @mdboom
    Contributor

    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).

  2. mdboom commented on Dec 19, 2012

    @mdboom
    Contributor

    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.

  3. embray commented on Dec 19, 2012

    @embray
    MemberAuthor

    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.

  4. eteq commented on Dec 20, 2012

    @eteq
    Member

    @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...

  5. mdboom commented on Dec 20, 2012

    @mdboom
    Contributor

    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...

  6. astrofrog commented on Dec 20, 2012

    @astrofrog
    Member

    Maybe decompose could take an optional argument, si or cgs, and the latter would implicitly call decompose().cgs?

  7. mdboom commented on Sep 4, 2013

    @mdboom
    Contributor

    I think this is at least partially resolved now, since you can do:

    u.erg.decompose(bases=u.cgs.bases)
    

    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.

  8. mdboom commented on Oct 21, 2013

    @mdboom
    Contributor

    I'd like to close this -- I think we've found a better solution in the meantime. @embray?

  9. embray commented on Oct 23, 2013

    @embray
    MemberAuthor

    Yeah, the bases approach is a sound resolution to this issue.

  10. added a commit that references this issue on Jul 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions