Potentially switch to fully composable units without unit systems about dimensioned HOT 12 CLOSED

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.

from dimensioned.

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

from dimensioned.

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?

from dimensioned.

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 [email protected]
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
#2 (comment).

from dimensioned.

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

from dimensioned.

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 [email protected] 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
#2 (comment).

from dimensioned.

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

from dimensioned.

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

from dimensioned.

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 [email protected]
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
#2 (comment).

from dimensioned.

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.

from dimensioned.

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.

from dimensioned.

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

from dimensioned.