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

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-13 11:08:04

On 10/13/05, Deane Yang <deane_yang_at_[hidden]> wrote:
>
> Mathematically, I think Andy is entirely correct in what he says above.
> Once you take the ratio of two measurements of the same dimension (or
> quantity), you end up with a pure number that really can't be
> distinguished from other ratios or pure numbers.

I tend to disagree here. A ratio of two lengths, for example, is in fact a
value in radians. For instance, a radian angle measure is formed by dividing
an arc length by the corresponding radius. Both arc length and radius are
units with a length classification. As such, the result is a unit having a
derived classification with fundamental parts cancelled out (as described by
SI units) and has the SI unit type of radians. If anything, as I described
earlier, I believe implicit conversion from that type to a raw value may be
allowable, such that they can easily be used with functions which take raw
values, however storing them directly as raw values is not a good idea.

Take this situation, for example, if one were to choose to make the result
of length / length simply a raw value. What happens if you have:

arc_length / radius + quantity< degrees >( 90 );

If you choose to have the result of the first operation be a raw value as
opposed to a radian value, then what do we do here? Andy states that the
operation shouldn't be allowed, however, I believe it should, since
arc_length / radius is in fact an angle. The only way I see around this
other than having the division result in radians is to always assume that
numeric values without explicit units attached to them are in radians. If we
do this, then we run into the problem that since we now store calculations
which result in radians as simply raw values, multiplying together two
radian values (now represented as raw values) will not result in steradians!
The result of a raw value times a raw value would just be another raw value,
which you have always assumed to be in radians, when in actuality it is not
the case, since now they are logically steradians even though you have not
represented them as such.

This goes back to what I've been attempting to explain -- a radian when
formed by the division of two lengths is still a radian and should have that
information attached to it, otherwise the value cannot be used unambiguously
in further expressions. Steradians and radians, just like my example of
degrees^2 and degrees, are entirely different concepts, and representing
radians as just raw values would be getting rid of the ability to have that
difference in types. Thus, as soon as one starts working with concepts such
as angles, much of the safety and proper implicit conversionsthat the rest
of the library has would be lost.

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

> Could you remind me what operations are permitted with an "empty
> classification"? What happens if you take the ratio of two values with
> the same empty classification? Are you allowed to feed it into the
> exponential function?

Everything that is allowed with units of other classifications. Intuitively,
I believe that a quantity with an empty classification divided by a quantity
with an empty classification would result in another value with an empty
classification. Just like with length and length, the result would have an
empty classification, however it would still have units associated with it,
just like other calculations using quantities. If I decide to go the route
of having units with an empty classification able to be implicitly converted
to raw values, then yes, you would be able to feed them to math functions,
such as those in <cmath>, taken that you are using standard types of course.
Just so we're clear, if we allow this implicit conversion for simple ratios
such as radians, I believe the same would have to be allowed for degrees and
other simple angle unit types since logically they are just ratios as well,
only represented under a transformation. The result of converting a degree
to a raw value would be the equivalent of converting it to radians and then
returning that value.

--
-Matt Calabrese