Re: [boost] Re: new compile-time dimensional analysis and unitlibrary

From: Phil Richards (news_at_[hidden])
Date: 2003-12-17 13:32:15

On 2003-12-17, David B. Held <dheld_at_[hidden]> wrote:
[...trim...]
>  My answer to theta * theta is m^2/m^2, which looks like a ratio
>  of areas.  So maybe you could call that "radians squared", or
>  rad^2.

Or "steradian", since that is precisely what a "steradian" is
defined as being in the SI unit system.  The problem is that an
"angle squared" is not a "solid angle"...  Compare this with
Length, Length^2 and Area.  The latter two do mean the same
in a physical sense.

>  Or instead, you could cancel one set of meters, and
>  reduce it to m/m, or "meter radians".  Then, when you add it
>  to phi, you are adding like units.

I agree, sort of.  But again I highlight the difference between
dimension and unit: you are adding like dimensions, but different
units.  Probably.

[wrt "length * angle == length"]
>                                            The trick is that we
>  automatically "reduce" radians in our heads when we don't
>  want them to appear any more, and for radians to behave as
>  we expect, the library must do the same thing.

I don't think people do reduce them - they are looking at a
different thing: dimensional analysis, and radians have no
dimension so don't "count".  But this is getting a bit
philosophical, and isn't really that important over all :-)

> As far as I can tell, radians need to have these properties:
> 
>  1) Implicit conversion from a unitless value.
[...]

Agreed.

>  2) Fundamental arithmetic operations taking only radians
>  or unitless values return radians.

I thnk they should probably return the same type as the
arguments.  Basically, for dimensionless units, the operations
on the type delegate directly to the underlying values
and leave the units alone.[1]

Are you covering the case of:
    radian + double => radian
when you refer to "or unitless values"?  That's how I read
it (and would agree with you).

>  3) Operations involving "unit-ed" values "reduce" the
>  radians.
>      rad + length = length

I think additive use is bad - it blows dimensionality checking
out of the water...

>      rad * length = length

 ... multiplicative is fine.

>  If the library could offer this behavior, I think it would solve the
>  problem of sin(rad x) as well as m * rad = m, and all the other
>  peculiarities of angular measures.  Or maybe that's just
>  unwarranted optimism, I'm not sure.

I *really* need to get some docs written for my attempt at all this;
it does 1, the additive part of 2, and all of 3 (excepting my
disagreement over the additive behaviour).  Maybe I should just
put in on yahoo warts and all.

I have deliberately avoided getting bogged down in angles to any
great extent - I did an experiment with "SI angles are dimensionless
in radians", and "Imperial angles are dimensionless in degrees",
with appropriate conversion between the two.  However, that feels
uncomfortable - are degrees and radians *really* specific to any
particular unit system?[2]

[1]+[2]:
Perhaps trying to ram dimensionless unit handling into
exactly the same framework as dimensionality checking is wrong;
perhaps dimensionless stuff needs a parallel, but interoperating,
structure.

phil
-- 
change name before "@" to "phil" for email