Re: [boost] Re: Units (and operators.hpp, too)

From: Corwin Joy (cjoy_at_[hidden])
Date: 2001-06-28 23:09:30

I think that having a nice templated units library
would be cool.  One thing that seems to be missing
from this discussion, however, is that the templates
should have virtual base classes which expose operator
+ and * such that developers can
use the units classes for either compile time checks or runtime
checks.  In my work, I do a lot of units conversions
but these have to be checked and cast at runtime
for three reasons:
1.  I'm reading the values and units from a database and I
don't always know what possible units are allowed in advance.
2.  I often have to cast and format out reports in different
units of measure depending on how the end users
prefer to view their results.
3. The unit conversion ratios for me will often change at runtime,
potentially minute-by-minute
e.g. how much is a Mexican Peso worth in US $ today,  (exchange rate)
. how much is a Mexican Peso to be delivered in 1 year worth in US $ today
(exchange rate) * (Mex discount factor at 1 year).
These kind conversions all benefit from a strict units regimen, but it needs
to happen at runtime.

I pretty much agree with Deane about the difference
between points ("affine units") and distances ("linear units").
I do have a few objections tho:

> -----Original Message-----
> From: Deane_Yang_at_[hidden] [mailto:Deane_Yang_at_[hidden]]
> Sent: Friday, 29 June 2001 3:23 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Units (and operators.hpp, too)
>
>
<..snip..>
> 2) It is important to identify "unitless" quantities
>
> It is obvious that the ratio of two quantities with the same units
> must be unitless. What is not always so obvious is that some "units"
> are really unitless quanities. The two I know about are percentage
> (which is obviously a ratio) and radians.
>
> And then there are quantities that seem unitless but are not.
> The simplest example is an interest rate, which is always
> stated as a percentage. To see what it really is, you just
> ask yourself how it's used in a formula. The first thing you
> always do is multiply the interest rate by a time and get a
> ratio (interest/principal). So the units
> of an interest rate are always given by 1/(time unit).

Sort of, there are different time units, tho, depending on the interest
rate convention.  Example daycounts that are applied to
interest rates include

Actual/365,  30/360, Actual/Actual, business/260 etc.
>
> 3) Transcendental functions
>
> Any standard transcendental function, such as sin, cos, exp, log,
> MUST take only unitless quantities and return unitless quantities.
> If not, there is an error in the formula. You can sort of see why by
> observing that these functions are computed using a Taylor series
> with unitless coefficients and there is no way to have every term in
> the series have the same units unless the argument is unitless.

I'm not sure I agree with sin & cos, but I definitely *disagree* for logs.
It seems to me that the log of a unit has well defined units.
e.g.
distance d1 = 5*meters;
distance d2 = 10*meters;
distance d3 = exp(log(d1 + d2)); // 15 meters
area       a1 = exp(log(d1) + log(d2)); // 50 meters^2

i.e. in general log(measurement) has a unit that is the log() operator
applied
to the individual units.  Naturally supporting these is more complicated
since taking the log of a measurement then swaps the role that
multiplication
and addition play.  I can certainly see why one might draw the line
at function checking.