Re: [boost] Re: A Physical Quantity library for boost?

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-25 21:25:51

Kevin Lynch wrote:

> However, I've never seen an expression with logarithmic units.

        Sure you have: how about 100 decibels? :-)
 
> You wound me good sir!  We physicists would never traffic in "kludges"
> :-)

        You don't? The what DO you guys do? :-)
 
> 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).  

        I agree. The problem is how to keep the 'weird' units that
make no sense by themselves alive in the partial results.

        Another example is imaginary numbers. Most physicists
don't produce imaginary complete results, but those things
get into the middle of calculations all over the place. :-)

[sin  is pure]

You could argue that 'multiply' is also pure.
And this is what normal (undimensioned) calculations do:
you just use pure numbers all the way through, on the basis
the dimensions always cancel out.

I.e. if you can cancel dimensions by

        sin ( x / L ) * metres

why shouldn't you have to do that for multiply too:

        (x / L) (y/L) * metres(2)

> 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.

        OK. I think you're right.
 
> 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; 

        you do have your way: its your library!

> 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.

        I think you can do that with lazy evaluation.
Non-trivial though. For matrix quanitites, though, it proves
very useful: saving even one step can be significant.

        Anyhow, I think the library is a good idea.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net