[boost] Controversy over angles in radians

From: Deane Yang (deane_yang_at_[hidden])
Date: 2003-12-16 22:41:56

I'm only a mathematician, so I do not really know what the precise
definition of a "physical dimension" is. But on purely mathematical
grounds, I agree that radians have special status.

Although radians clearly are units, an angle given in radians is also
a pure unitless
ratio (the ratio of the circular arc cut out by the angle over
the radius of the circle) and, as has been observed by
others, therefore can be used in two ways
that quantities given in units normally cannot be:
1) You can multiply a length by a
n angle in radians and get a length.
2) You can feed an angle in radians into a pure mathematical
nonlinear function.
In both cases, the angle in radians is being treated as a pure
unitless real number expressing a ratio, rather than a quantity
with units.

So, for a while, I also felt that it was impossible to define radians
as a unit within a C++ units library.

But on further thought I now feel differently. You CAN define radians
as a unit and, contrary to some of the objections, it IS useful to do 
so. For example, suppose I want to write some generic numerical code 
involving angles, but without being unit-specific. Two simple examples
are:

// Function for computing the length of a circular arc
template <class length_units, class angle_units>
length_units arc_length(length_units radius, angle_units angle);

// Sine function
template <class angle_units>
double sine(angle_units angle);

I would want this to work with either degrees or radians,
and I would want the unit library to sort this out automatically for me.
I think this is important in many scientific and engineering applications.

But what if you want to treat an angle in radians as a pure unitless
ratio and use it as in 1) and 2) above? Well, if you think in terms of
generic code, the answer is obvious. If you have an angle given in 
unspecified units, you have to convert it to a pure double by computing
the obvious ratio and use that double. In fact, that's exactly how you 
would implement the two functions above. Inside the implementation,
you would always represent angles in radians, and using the unit library
for angles is inappropriate AND unnecessary.

It appears to me that any code involving angles can be divided cleanly 
into two pieces, one where angles are viewed as quanitities
defined with respect to a unit and one where angles are viewed as pure
ratios. Roughly speaking, the former is usually the library interface, 
and the latter is the implementation. I would use the units library for
the former and represent angles as doubles (and in radians) for the latter.

Finally, if all of the physicists agree that angle is not a physical 
dimension, then it certainly should not appear in a dimensions library.
Just in the units library.

Phil Richards wrote:
> On 2003-12-16, Matthias Schabel <boost_at_[hidden]> wrote:
> [...trim...]
> 
>>There are a couple of options for those who don't feel that degrees and  
>>radians should be classified as units:
> 
> [...]
> 
> There is no doubt that degrees and radians are units.
> 
> This distracts from the fact that the primary purpose of the
> library that is being written is dimensional analysis - and this
> is orthognal to units.  A length is a length whether it is in the
> SI unit system (and represented as meters) or in the Imperial
> unit system (and represented as feet).
> 
> Angles are, within a dimensional analysis context, usually
> viewed as dimensionless - but they are not unitless - we have
> radians and degrees, after all.
> 
> But we all know this.
> 
> 
> There is a clear definition of what the physical dimension of
> an "Angle * Angle" is: it is "zero" (dimensionless, if you
> prefer).
> 
> 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.  I have to say I disagree with YANL on:
> 
>     SI<double>::Length(2.0) * (1.0 * _radians)
> 
> generating a value of:
> 
>     2 m rd
> 
> 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 think much of the disagreement/confusion in this debate comes
> from trying to solve 2 different problems by combining them
> into one, incompatible one.
> 
> phil
> 
> p.s.  I can't help but feel the discussion is getting a little
> more excited than perhaps it needs to be.  We are, after all,
> only talking about a C++ library...