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

From: Deane Yang (deane_yang_at_[hidden])
Date: 2005-10-13 11:48:13

Matt Calabrese wrote:
> 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.

This, I don't understand. If I have a right triangle and take the ratio 
of the "opposite side" over the hypotenuse, what I get is something that 
I would not view as being in radians, it is in "units" of 
"sin(radians)", if you really want to assign units to it (but once you 
allow nonlinear functions of units, you really have a mess, I think).

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

Do you distinguish between meters-measuring-linear-length and 
meters-measuring-arclength? Is it desirable to do so?
> 
> 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.
> 

I'm sorry, but I don't consider degrees to be pure ratios or pure 
numbers. Degrees should be viewed as the arclength of a piece of a 
circle that has circumference equal to 360.

Given an angle x in radians,

sin(x) = x - x^3/3! + .....

Does your approach to radians work coherently with this formula? In 
other words, does it assign the right "units" to each term and to the 
"sin(x)"? I don't see how this can be done, because x^3/3! has to have 
the same units as x in order to allow the addition.

Unlike for dimensional quantities, I don't have a coherent mathematical 
theory for unitless quantities, but my observation has been that "pure 
mathematical functions" like exp, log, sin, cos can only accept and 
return pure unitless ratios (like radians but not degrees). I don't see 
any way to impose any coherent system of units in a mathematically 
precise way.