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