
Boost : 
From: Kevin Lynch (krlynch_at_[hidden])
Date: 20010625 11:37:18
John Max Skaller <skaller_at_[hidden]> wrote:
> > 3) Does anyone see any fatal flaws in the general approach,
>
> It looks good to me.
>
> Some operations seems to be missing.
> Suppose I write:
>
> pow(x,y)
>
> and x,y have units. What is the result?
> Here, x is in metres, so the argument to sqrt is
> square metres, and the result should be in metres.
> More generally, root(n,x) yields division
> of the dimension by n
Yes
> (and an error if it isn't
> integral  unless you want to support fractal dimensions :).
This would be a mistake. Noninteger dimensions come up all over the
place in physics (particularly astrophysics), although they are usually
rational fractional powers (3/2, 9/7, etc...). Typically, you have an
expression that goes like alpha T^n, where n = 7/2 (or something), and
the units of alpha are the same as T, but raised to some power like
5/2. Consider also an expression written as
sqrt(x)*sqrt(y)
where x and y have units of length. This type of thing should not
fail. Yes, you could require the user to rewrite it, but consider that
such an expression might be embedded into some larger equation, and it
is not immediately obvious that it needs to be rewritten. Or, as is
often the case in numerical work, you have to torture an equation so as
to ensure that you don't incur overflow inside a calculation when the
outermost result should be representable. This can lead to the same
unit situation.
> pow(x,n) yields multiplication of the unit by n.
Yes
> So log(n,x) also yields division. (Guess?)
>
If n is the base of the logarithm, and x the argument, the units of such
an expression are independent of n, i.e. log([x]) where [x] is teh
"units of" operator. This is because of the relations of logarithms of
different bases
log(n, x) = log(m, x) / log(m, n), and log(ab) = log(a) + log(b)
However, I've never seen an expression with logarithmic units.
> When it comes to trig functions ...
> I guess I'm saying: dimensional correctness is a problematic
> thing in physics, because all sorts of approximations
> and kludges and special functions are used.
You wound me good sir! We physicists would never traffic in "kludges"
:)
Seriously, though, it is important to note that none of the
approximations, kludges, and special functions we use in physics ever
EVER make the units of the final result incorrect (if they did, the
result would be obviously wrong, and would never see the light at the
end of the peer review tunnel). In particular, the "special functions
of mathematical physics" always take dimensionless quantities as
arguments. If you want to take the sin(x) where [x] = length, then you
are almost always doing something wrong, because you really want
sin(x 2pi / L)
or something similar instead, where [x] = [L], and L is some
characteristic length in the system.
It certainly might be useful to have an "undim(x)" function, but if you
are properly handling your physics equations, it should never (strictly
speaking) be necessary. It is kindof like casting away const  sure,
you really really need to sometimes, but most of the time it is
indicative of an error on your part to need to do so.
If I had my way, such a library would specifically generate compile time
errors if you tried to apply a special function or logarithm to a
quantity with dimensions; in such a case, the programmer is undoubtedly
"wrong" in what they are trying to do, and the library should provide
you no assistance in trying to "fix" the problem. If you really really
think you need to, you should have to do so explicitly, it should be
made ugly and horrible so as to indicate the seriousness of the breach,
something like
remove_dimensions(x)
instead of "undimen(x)", which is just too nice :)
The main use I actually see for such functionality is to improve
efficiency inside calculations. First, you write your code to produce
the inputs to some algorithm, units and all. Then, inside the
algorithm, the units are checked, converted if necessary, and then the
stripped off so that the algorithms run on (probably) more efficient
fundamental types. At the end, you take the result, tack on the
appropriate units, and spit out the results.
  Kevin Lynch voice: (617) 3536065 Physics Department Fax: (617) 3536062 Boston University office: PRB565 590 Commonwealth Ave. email: krlynch_at_[hidden] Boston, MA 02215 USA http://physics.bu.edu/~krlynch 
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk