# Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2003-12-16 22:58:07

"Phil Richards" <news_at_[hidden]> wrote in message
news:20031216205032.4772D8C016_at_derisoft.derived-software.demon.co.uk...
> [...]
> I haven't, I admit, got a clue what the *unit* of angle-squared
> is in the SI system - the most obvious would be steradian,
> but that just feels plain wrong. And, as has been pointed
> out, it is not unusual to have equations like:
>
> theta*theta + phi
>
> where any obvious types of "unit" (not dimensional) arithmetic
> don't seem to make sense.

Well, it makes sense if you view an angle as a ratio of length
which would simply be rad = m/m or rad = ft./ft. But since the
units also cancel, it is equally legitimate to say that a value in
radians is simply a value, and not a unit-related quantity. 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
reduce it to m/m, or "meter radians". Then, when you add it
to phi, you are adding like units.

> I have to say I disagree with YANL on:
>
> SI<double>::Length(2.0) * (1.0 * _radians)
>
> generating a value of:
>
> 2 m rd

This is perfectly reasonable to me, but I think the problem lies
elsewhere.

> There are way too many places where "angle * length"
> are expected to return "length" to make this type of
> dimensional analysis feel correct. But maybe that is just me.
> [...]

I'm sure a lot of people agree with you. The trick is that we
want them to appear any more, and for radians to behave as
we expect, the library must do the same thing. As far as I
can tell, radians need to have these properties:

1) Implicit conversion from a unitless value.

double x = 3.14;
foo(x);

2) Fundamental arithmetic operations taking only radians

3) Operations involving "unit-ed" values "reduce" the

```---