Re: [boost] [units]

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-03-07 11:47:30

Hi Deane,

> I am still skeptical for the need of anything fancy here. In my
> experience, fractional powers of units/dimensions are needed only  
> if you
> need to use such units in the interface. For example, in finance,
> volatility, which is in units of time raised to the negative 1/2  
> power,
> is a common input or output parameter.

I agree with you in principle that many of the fancy aspects are not
strictly necessary. However, we've designed the library with the
"principle of least surprise" in mind - anything that is reasonable and
can be implemented is allowed, and anything that is allowed should
behave in the most reasonable/expected way.

> Let me concoct an example: Suppose you have a funky force field F that
> depends on distance and velocity in some weird way. In particular,
> suppose that if distance is in meters and velocity is in meters per
> second, you've decided that the force in newtons is given  
> (approximately) by
>
> F(d, v) = d^{1/3} / v^{sqrt(2)} - v^{-5/4}
>
> You want to code this formula up so that you can input each of the
> quantities in different units from the original ones.
>
> The trick is to rewrite it as:
>
> F(d, v) = [(d/d_0)^{1/3}/ (v/v_0)^{sqrt(2)} - (v/v_0)^(-5/4}] * F_0
>
> where d_0 = 1 meter, v_0 = 1 meter/second, and F_0 = 1 newton.
>
> Then if your library has implicit unit conversions, then formula  
> will be
> properly calculated, no matter what units the input values d and v  
> are in.

Of course this is fine, but it requires that you rewrite the  
equation, which
creates the potential for errors by itself. In addition, as Steven  
pointed out,
you may not have control of the function.

> But surely I'm telling you anything new? I'm pretty sure I learned
> tricks like this from physicists. So I still need an example where  
> this
> approach does not work or where the extra divisions cause a serious  
> problem.

As a physicist, of course I know these tricks. However, there are  
issues of
efficiency to consider - if the equation you wrote above is expressed  
in SI
units, then it is possible to do the de-dimensionalized calculation  
with no
computational overhead above the actual function evaluation (that is,  
the
divisions by units don't incur additional overhead). However, if you  
pass
non-SI units to the function, you will incur unit conversion  
overhead.  In
addition, the library we're proposing is trying to provide three things
simultaneously :

1) safety by performing rigorous unit checking on expressions that are
as close to arbitrary as possible
2) convenience of expressing dimensional equations in any sensible way
3) zero runtime overhead

While there are limits to what can be accomplished, I think we've  
actually
done a pretty good job of meeting these objectives...

Matthias