Potentially switch to fully composable units without unit systems

[llogiq]

We should really try moving this to typenum. Perhaps while we're at it, we may want to get away from the dimensions-tuple and use a more dynamic approach that allows us to more freely match unit types. I'm thinking about a mapping from unit to exponent, which could be implemented

• very naively using a type-level linked list of (unit, exponent) tuples, where applying a (unit, exponent) type means a linear search for each type, though this can be quite slow as our number of units grows; merging would be in O(n²)
• a little bit more sophisticated as a binary tree, which would however require an ordering, but would merge in O(n log n)
• use a GenericArray-like approach to create generic arrays of (unit, exponent) tuples, perhaps with a default (NoUnit, Zero) value to create a HashMap-like structure, which would merge in O(n).

[paholg]

If I understand you correctly, your proposal is to do away with unit systems and make it so any units can interact?

I've thought about this before, but couldn't come up with something satisfactory. I am happy to make the change, though, if we can find something that works and is reasonably fast.

I think that means your first suggestion is out.

For the second, I'm not sure how to come up with an ordering that would work for units defined in different crates (this what I was thinking about trying in the past). Now that I think about it, we could define types for each letter, then an ordering among them, so the type Meter would have the associated array-like structure [M, E, T, E, R]. This may lead to interesting collisions if the same unit is defined in multiple crates.

Your third suggestion sounds the most promising, although I don't have a deep understanding of hash maps, and it would likely be the most complicated to implement. I'm pretty busy the next few days at least, but I will do some reading and see if I can come up with anything.

As for using typenum instead of peano, that should be almost as trivial as doing a find-replace for those two terms, I've just been lazy and caught up with other things.

[llogiq]

Ok, I've been doing the seek/replace dance to move from peano and typenum. I still have a few errors (first it was about missing Copy, but after a cargo update it's about conflicting typenum::Same implementations.

I'll push a PR shortly. Perhaps I can even shake out that one bug before...

[brendanzab]

Perhaps while we're at it, we may want to get away from the dimensions-tuple and use a more dynamic approach that allows us to more freely match unit types

Would love to see arbritrary unit combinations! Would make this library much more appealing! Relevant thread on Reddit. Please forgive my misguided claims. :)

Should that be in a separate issue?

[droundy]

I do have doubts about the correctness of arbitrary unit combinations. What happens if you mix up SI and Gaussian units? There is no way to convert between then! Presumably you call that user error.

I will say that there is an appeal to being able to treat things like number of hydrogen atoms as a unit and the molar mass of hydrogen as a unit conversation...

On Tue, Dec 1, 2015, 9:45 PM Brendan Zabarauskas notifications@github.com wrote:

Perhaps while we're at it, we may want to get away from the dimensions-tuple and use a more dynamic approach that allows us to more freely match unit types

Would love to see arbritrary unit combinations! Would make this library much more appealing! Relevant thread on Reddit https://www.reddit.com/r/rust/comments/3uplr7/stronger_type_system/cxgur50. Please forgive my misguided claims. :)

Should that really be in a separate issue?

— Reply to this email directly or view it on GitHub https://github.com/paholg/dimensioned/issues/2#issuecomment-161161660.

[llogiq]

@droundy Really no way to convert between them? I thought this could be done via Maxwell's equations, but I'm just a CS guy, not a physicist... that said, you're right that having exactly one system of unit (say, SI) for a project has its value, too.

[droundy]

The problem is that SI defines different units for various quantities where Gaussian (and other systems) define just one. Imagine if you used leagues for horizontal distance, but fathoms for vertical distance. You'd have a constant for conversion between them (which would show up in your version of Pythagoras' equation), but there would be no way to convert a distance in meters into those weird units, since you wouldn't know if it was a vertical or horizontal distance. SI is like those weird units, but sadly is sufficiently entrenched that we can't ignore it.

Of course, a relativist will tell us that both Gaussian and SI units do the same kind of thing with distance and time, and that the speed of light c is just a pointless unit conversion caused by using units developed more than a hundred years ago.

On Wed, Dec 2, 2015 at 12:57 PM llogiq notifications@github.com wrote:

@droundy https://github.com/droundy Really no way to convert between them? I thought this could be done via Maxwell's equations, but I'm just a CS guy, not a physicist... that said, you're right that having exactly one system of unit (say, SI) for a project has its value, too.

— Reply to this email directly or view it on GitHub https://github.com/paholg/dimensioned/issues/2#issuecomment-161380842.

[brendanzab]

Hmm, I wonder if boost.units has a solution...

[brendanzab]

I would also look to see if there is a solution in the F# world - they also have open units of measure.

@droundy So are you saying you'd rather have closed unit systems due to the incompatibility of some systems possible allowing for non-sound combinations of units? Or are you just saying it would be hard to make conversions between some? If it is the latter, than isn't that already a problem with dimensioned? I could be wrong...

[droundy]

I mean that an open set of units may be incorrect. That might not be an essential problem, but my motivation for using dimensioned (if I do use it) would be to statically enforce correctness. Of course, if you only use a consistent set of units, then keeping it open would not lead to incorrectness, so it isn't inherently bad. But it does open up the possibility of users getting incorrect results... or more likely for correct computations to be impossible to express.

On Wed, Dec 2, 2015 at 4:54 PM Brendan Zabarauskas notifications@github.com wrote:

I would also look to see if there is a solution in the F# world - they also have open units of measure.

@droundy https://github.com/droundy So are you saying you'd rather have closed unit systems due to the incompatibility of some systems possible allowing for non-sound combinations of units? Or are you just saying it would be hard to make conversions between some? If it is the latter, than isn't that already a problem with dimensioned? I could be wrong...

— Reply to this email directly or view it on GitHub https://github.com/paholg/dimensioned/issues/2#issuecomment-161445590.

[paholg]

I think it makes sense to ask what do we really gain with fully composable units?

The only things I can think of are unit conversions between systems and the ability to use units defined in a different crate, but add units to them. For example, if you depend on a crate that uses SI, and you want to use SI but also have angles.

Is there anything else?

It would probably be easier to solve these problems than to go for a unit system-less approach and lose potential correctness.

[brendanzab]

Yeah, I'm starting to see what you mean. Could we possibly leave this issue open as 'under consideration'? Would be useful if folks are looking at the library and maybe can give other use cases or solutions. Alternatively an FAQ could be added, pointing to this issue.

[paholg]

I think this is fairly settled that dimenionsed will always use pre-defined unit systems.