Re: A Physical Quantity library for boost?

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-06-25 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.  Non-integer 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:	 [phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------