Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2003-12-18 11:42:42

> 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

If I choose to use cycles as a unit of angular measure, they too are
_dimensionless_ ratio : the ratio of the circular arc length subtended
the specified angle to the circumference of the circle.

> 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.

This holds true for any dimensionless quantity, technically speaking.
question here is whether the dimensionlessness of a quantity should
the units associated with that quantity. That is, radians (and degrees
and all other
units of angular measure) are dimensionless quantities having distinct
units. If
I specify to an engineer that the angle between two planes should be
0.25 (a pure
number), you can be sure that she will come back to me with the
question : 0.25
what? So it is clear that the angular quantities are in fact not pure
numbers - the
number itself is not sufficient to fully specify the quantity.

> 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.

Again, this is just a consequence of the fact that the Taylor series
expansions of
commonly used functions are particularly simple when expressed in
radian measure.

> 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.

Thank you - this is precisely what I've been trying to get at.

> 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.

Absolutely - I've never proposed changing the underlying
implementations of trig functions (or other functions) - using radians
is obviously the best implementation. But, as you've observed, from a
practical standpoint being able to trap degree/radian mismatch errors
is a desirable goal (unless your philosophical attachment to a
particular dogma trumps your pragmatic interest in producing clean,
error-inhibiting code).

> 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.

As it stands now, radians do not appear in the dimensional analysis
code, only in the implementation of the SI unit system.

Matthias Schabel, Ph.D.
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
mschabel at ucair med utah edu

Boost list run by bdawes at, gregod at, cpdaniel at, john at