Re: Quantity libraries: SIunits

From: Deane_Yang_at_[hidden]
Date: 2001-09-14 23:20:16

Thanks for a very convincing example of why you might mix 
different units for the same "dimension". It now does make 
sense to me that a physicist would rather work with objects that 
represent physical quantities ("dimensions") without any specific 
reference to the units.

So I retract my statements about physics software. I stand by
everything else I said, though. It seems to me that for some
software, you want to be able to write:

time = distance / velocity

and have it compile, no matter what the units were used to 
construct each object, but for other software you would want to 
associate specific units to the objects and to have

time_in_seconds = distance_in_cm / velocity_in_mph

to give a compiler error. Most of my work falls in the latter 
category. That's why I'm asking for the more basic library
that does not have automatic conversions between units that 
measure the same quantity.

Deane

--- In boost_at_y..., "George A. Heintzelman" <georgeh_at_a...> wrote:
> 
> 
> > I too am curious how this would come up.  I can think of 
function that
> > would have a signature of:
> 
> > 	mass/volumn density(mass m, distance r)
> > 
> > but why would you want two fuctions:
> > 
> > 	kg/m^3  density(kg m, m r)
> > 	kg/cm^3 density(kg m, cm r)
> 
> Sure, I can come up with an example. Suppose you want to 
know how much 
> energy is being delivered by a particle accelerator. You're a 
doctor 
> calculating a dose for a patient, so you want the energy either 
in ergs 
> or calories (I'm not really sure what doctors will use, but it's
not 
> electron volts). On the other hand, the energy of the beam is 
typically 
> measured with two quantities: first, the energy of a given 
particle, in 
> some electron-volt scale, and the luminosity of the beam, in 
units 
> which can be converted to particles per second (luminosity is 
more 
> complicated than this, but let me finesse this for purposes of 
the 
> example). Your calculation will be something like:
> 
> 	energy/particle * particles/second * seconds of exposure
> 
> but you will want to implicitly convert from MeV/second to ergs/
second.
> 
> I'm sure this is not the only example. There must be many 
examples 
> where calculations need to cross domains in which the 
conventional 
> units are different.
> 
> Now, SIunits handles this, as best as can tell, transparently 
and 
> easily. That is IMHO how it should be. A programmer should 
not need to 
> worry about whether her internal representation is in inches or 
> centimeters or light-seconds, unless she is running up 
against 
> representable range issues, and then she will work hard to get 
it 
> right. SIunits allows you to do this with limited manual 
intervention 
> needed,  by defining your own view, defining the conversion 
constants 
> once from the fundamental representation. This is IMHO how it 
should be.
> 
> > So I see the need for having IO from and into various units.  
But once
> > inside C++, I'm not sure why you would mix units.
> 
> You need to have the ability to represent different units for 
> representable range issues, primarily. Representing 
cosmological 
> distances in femtometers or particle physics lengths in 
megaparsecs is 
> going to run into trouble, especially when you cube lengths to 
get 
> volumes.
> 
> Once you have the ability to represent measurements in 
different views, 
> you naturally are going to have potential incompatibilities 
between 
> different libraries which make different natural choices of those 
> views, so supplying the conversions becomes important.
> 
> George