Re: [boost] Interest in dimension/unit-checking library?

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-20 14:02:01

On 10/20/05, Deane Yang <deane_yang_at_[hidden]> wrote:

> And if I recall correctly that was the problem with some space mission
> that went wrong. I just don't think implicit conversion of units would
> have been the right fix for that problem.

There is nothing logically wrong with the expression at all. If such a
mistake was made it wasn't because they mathematically shouldn't add inches
and meters, it's because they forgot to convert the units or because they
were adding together two unrelated values. If it was the former problem,
this is already solved since the conversion is automatic. If it was the
latter problem, it, again, has nothing to do with the fact that different
units were used, it's because they were adding together the wrong values.
Just as I described above, you can have the same problem if both quantities
had the same units. The reason why you shouldn't add them together has
nothing to do with the units used, it's because there is a higher level
abstraction that isn't represented. You can either choose to encapsulate the
two quantities with separate types to disallow the conversion, or you can
just add quantities together only where you should in your particular
project. Forcing explicit conversion does not "fix" any of this.

Adding a length with another length always makes sense. It's a higher level
of abstraction entirely specific to individual project which might make you
believe otherwise. Forcing explicit conversions does not solve this.

On 10/20/05, Deane Yang <deane_yang_at_[hidden]> wrote:
>
> Is it really sometimes necessary or desirable to write computation code
> that mixes different units for the same dimension? Is anyone patient and
> indulgent enough to explain to this naive mathematician why?

I am standing on a stool that is 3 feet high. I am 1.6 meters tall. Adding
the heights together describes how high above the ground I reach when
standing on the stool. The same applies to mass: my mass plus the mass of a
bowling ball, or anything else you can think of. Units are merely
implementation details to their dimension and should not directly affect the
way expressions combining them are written. Special cases occur, especially
in the "empty classification" (radians to steradians should not be
convertible), however this is specific to individual unit types, not general
to the entire system. Disallowing adding together two different lengths just
results in exposing implementation details to high-level code. The point in
having them be two different units of the same dimension is to show that
they express the same thing just with a different representation. Since they
represent the same exact same concept there is absolutely no reason why you
shouldn't allow
them to be used in the same manner.

Again, all of the "problems" you describe have nothing to do with the units
used, but rather occur because of an unrepresented abstraction in your
specific project. Encapsulate the different types separately if you want
that abstraction as it has no place in a units library as I see it.

--
-Matt Calabrese