
Boost : 
From: Andy Little (andy_at_[hidden])
Date: 20051013 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. Dimensionalanalysis sees
all dimensionless types as dimensionallyequivalent. If they are
dimensionallyequivalent 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 angularvelocity 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk