|
Boost : |
From: Deane Yang (deane_yang_at_[hidden])
Date: 2005-10-13 09:41:19
Andy Little wrote:
> "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.
>
...
> 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.
>
I can't claim to have understood all of Matt's discussion about this
and, as always, I am of two minds on this.
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. For example, notice
that it is useful to feed pure numbers or ratios into nonlinear
functions such as the exponential and logarithm functions (as well as
trig functions). Such functions are pure mathematical functions that can
only take pure unitless numbers as inputs and return unitless numbers as
outputs.
On the other hand, when coding, it would be nice to be able to protect
against mixing radians and decibels inappropriately in the same formula,
so assigning different types to them is an attractive idea. I have
experimented with this, but have not found a satisfactory solution myself.
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk