Boost logo

Boost :

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.


--- 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
> 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
> electron volts). On the other hand, the energy of the beam is
> measured with two quantities: first, the energy of a given
particle, in
> some electron-volt scale, and the luminosity of the beam, in
> which can be converted to particles per second (luminosity is
> complicated than this, but let me finesse this for purposes of
> 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/
> I'm sure this is not the only example. There must be many
> where calculations need to cross domains in which the
> units are different.
> Now, SIunits handles this, as best as can tell, transparently
> 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
> representable range issues, and then she will work hard to get
> right. SIunits allows you to do this with limited manual
> needed, by defining your own view, defining the conversion
> 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
> distances in femtometers or particle physics lengths in
megaparsecs is
> going to run into trouble, especially when you cube lengths to
> volumes.
> Once you have the ability to represent measurements in
different views,
> you naturally are going to have potential incompatibilities
> different libraries which make different natural choices of those
> views, so supplying the conversions becomes important.
> George

Boost list run by bdawes at, gregod at, cpdaniel at, john at