"Matt Calabrese" <rivorus@gmail.com> 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@servocomm.freeserve.co.uk> 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@servocomm.freeserve.co.uk> 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