Re: [boost] Re: Re: Re: Re: quantity libraries

From: Matt Austern (austern_at_[hidden])
Date: 2001-08-31 11:51:41

Kevlin Henney wrote:

> Sorry, I should have been clearer, this is not quite what I meant:
> moving between inches and millimetres is a relatively common
> translation, but they are not orders apart in the magnitudes and
> significant figures they address. This is already covered by having the
> program compile using SI units as its base, and providing constants for
> inches etc, and address presentation through locales or explicit
> functions.
> 
> Specifically what I was after was whether anyone was mixing radically
> different units that would suggest favouring two different underlying
> representations, eg megaparsecs and femtometres, and what issues they
> had encountered and resolved.

I'm more familiar with the very small units than with the very large,
but in my experience it's quite common to convert between (say) electron
volts and joules, and between meters and bohr radii.

It's slightly less common, but hardly unknown, to convert between 
electron volts and grams.  (You'll notice that in the SI scheme this
is illegal, because eV is a unit of energy and g is a unit of mass.
People who work in some disciplines of physics use a unit scheme where
mass and energy are the same dimension, and where length and time are
the same dimension.  In this scheme, 2.99792458x10^8 m/s is just a 
conversion constant, just as 2.54 cm/in is just a conversion constant.)

There are two interesting issues.  The first is that in some kinds of
numerical analysis it's useful to have floating-point numbers of roughly
unit magnitude.  The second is that in some cases the conversion 
constants are experimental numbers with finite precision, rather than
defined values; the conversion factors may have to be updated when 
experiments get better.

I know that Walter Brown's SIUnits package deals with most of these
issues.  The only one I'm not sure of is the issue of normalizing
numbers to near-unit magnitude.  I think he always uses an SI internal
representation.

                        --Matt