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

From: Andy Little (andy_at_[hidden])
Date: 2005-10-13 06:41:41

"Matt Calabrese" <rivorus_at_[hidden]> wrote

> When you form a value from division of two quantities, it has units with an
> empty classification.

When you divide length by time you get another quantity.
When you divide a length by a length you get a number. Its that simple.

>Like the example I gave above, division of a circle's
> circumference by its radius gives you a result in radians, which is a unit
> which has an empty classification (such as with SI units).

The ratio of the circumference of two circles is a number. The ratio of two 
lengths is a number.
The ratio of two temperatures is a number. the ratio of two masses is a number.
Etc. No units involved there.

>An empty
> classification is not the same as a lack of units. Resulting in a raw value
> needlessly gets rid of this abstraction.

No . it gets rid of an unnecessary abstraction. Use a number to represent a 
number. Simple.

>> On 10/12/05, Andy Little <andy_at_[hidden]> wrote:
>> No... OTOH ...
>>
>> quantity<radians>(pi ) + 3.14159 ;
>>
>> ... I would have no problem with.
>
> That's because the number is in radians. Basically what you're saying is
> "assume all raw values are quantities in radians", which is not a valid
> assumption.

Please. I havent said that at all. I have found it useful in practise to provide
implicit conversion between radians and numeric types. Dimensional-analysis sees 
all dimensionless types as dimensionally-equivalent. If they are 
dimensionally-equivalent they are addable. Simple. radians unit  is useful for 
output but thats about it.

The tension (F = m *w^2 * r) in a string length r with a mass m at the end being 
whirled in a circle with angular-velocity w, is an
example. F doesnt have any angular information. In your library I assume this 
equation would be invalid?

>  As well, what type of quantity is 3.14159? Is it a scalar
> quantity or a vector quantity or a point quantity?
> If it is a vector
> quantity or a point quantity then that operation should not be allowable,
> since you can't add a scalar to a vector or point. Unfortunately, since you
> suggest to allow raw values, you lose this abstraction. The fact of the
> matter is, you creating ambiguity but then arbitrarily allowing certain
> operations.

numeric constants are not going to be allowed in the units library because they 
are ambiguous? Youre joking now right? :-).

> On 10/12/05, Andy Little <andy_at_[hidden]> wrote:
>> In pqs I assume that raw values are numeric. radians are different its
>> true.
>
> Then why did you state above that the radian value should be allowed to be
> added with the numeric? A quantity with units plus a raw numeric shouldn't
> make sense, even with radians.

In pqs addition of a numeric and a radian results in a radian . However I make 
it easy to lose the units. A radians type is mainly useful for output and for 
conversion to degrees.

cheers
Andy Little