Re:^5 quantity library

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-09-04 16:18:17

Paul Bristow wrote:

> The main potential problem is the astronomers, but even a megaparasec is only about 
> 3 million light years  where a light year is about 10^15 meter, the base unit.
>
> So even with float with a max of 10^38 there is quiet a bit of headroom, and with 
> double 10^308 there is plenty.
>
> So I can't see what the problem is with always storing everything in SI units.
>
> (If templating can allow other base systems without cost, then OK, but I think that 
> there is massive merit in having everything in SI internally, and a package that 
> does this is a must.

I disagree strongly; a "quantity library" which picked a unit system for
me would be worthless.  I am a particle physicist, and I use "natural
units".  The units of length and time are the same; the units of mass,
energy, momentum are the same, and the length and mass units are the
inverses of each other.  We also choose hbar = c = k = 1 (although, as
an aside, you could technically choose them to be any real number if you
wanted; 1 is just convenient in that dozens of conversion constants in
equations can be dropped).  Cosmologists often choose a system wherein
G=1 as well, and astronomers tend to work in the "parsec, solar mass,
second" system.  None of these users have any reason (except possibly to
convert experimental results from SI->natural once on input or
natural->SI once on output) to use any of the standard "non-natural"
unit systems in their conputations, but would very much like to be able
to write code which would protect them from making unit errors.  So if
the library required me to convert all of my equations to a non-natural
system, I would not be able to use it.

To me, the most useful approach would be (and this has been mentioned
before) to build a simple, fundamental "dimensions library" that did the
work of carrying around "dimensions" for you, aggregating them when you
multiply or divide etc and barfing when you try to add or subtract etc
dimensions that didn't match.  On top of such a library you could easily
build all of the types of "unit systems" (SI, MKS, CGS, FPS, natural,
etc) that people are talking about, with explicit or implicit unit
conversions, a fixed internal unit system, different numerical types
(reals, rationals, etc.), linear algebraic basis changes, financial
calculations with various types of 'days', proper handling of
transcendental functions and units, dealing with "large exponent"
conversion factors, etc.  

At least I THINK you could do this, although I haven't attempted to
design any such library. But I don't immediately see why this approach
wouldn't work, since it is how all "unit systems" are ACTUALLY
constructed and used.  I also don't see why it couldn't be small, fast,
and flexible enough to deal with all of the needs that I've seen people
mention.  You could build your own unit system (as I would, for natural
units), or use the predefined "SI module" that defines all the SI base
and derived units, but fails to define "english" units, or you could use
the predefined "SI module" with conversions defined to allow input
"english" quantities to convert to the appropriate SI units, etc....

The devil of course is going to be in the details.... maybe I'll think
about it some more than I have.  But the problems are going to be
basically the same as those involved in a library that picks a unit
system for the user, so I don't see any fundamental reason that this
approach will be any harder to implement.

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