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