String representation of Units not fully resolved when divisions are involved

Issue #1 new
Takayuki Muranushi
created an issue

Hello, thanks for your library. This seems very useful for my work! I like the extensibility the most.

Today, I have performed my first test on unittyped and found the following behavior.

-- expected: 480000.0 ¥ -- actually: 480000.0 man⋅month⋅¥/month/man

Is this a bug, or am I doing something wrong?


Comments (5)

  1. Thijs Alkemade repo owner

    Yeah, I'm aware of this problem.

    The problem is that the typechecker will realize that, for instance,

        (1 gram / second) * second


        1 gram

    have equivalent dimensions, so you can use .+. or .-. on them. And you can also use coerce to go from one unit to an equivalent one:

        *Main> coerce ((1 gram / second) * second) gram
        1.0 g

    However, units are treated very stupidly compared to dimensions, so this conversion is not (yet?) automatic.

    I'm still thinking about how to tackle this problem.

    I could use the same type-level mechanism that is applied to dimensions and apply that to units, meaning I represent every unit as a type-level map of base units to integer powers, like Meter^1 Second^-2. That will at least remove the obvious redundancies like 1.0 g/s⋅s.

    However, that will not do anything for (1 gram / hour) * second, as hour and minute are not the same unit.

    An other approach would be to have a function with takes a value, looks only at its dimension, and determines a "canonical unit" for it. So for length it woud always pick meter, and for time always second, so for 1.0 g/s⋅s it would pick gram, and then coerce to it.

  2. Thijs Alkemade repo owner

    Refactored everything to use maps for the units, just like for the dimensions.

    Pow is still broken, as is probably a lot of other stuff I haven't tested.

    Removed Currency, as it was controversial.

    Refs #1

    → <<cset da843cb1994d>>

  3. Log in to comment