Boost logo

Boost :

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-09-14 10:23:50

----- Original Message -----
From: Dean Foster <foster_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, September 14, 2001 10:48 AM
Subject: Re: [boost] Re: Quantity libraries: SIunits

> > From: Deane_Yang_at_[hidden]
> >
> > My gut instinct is that formulas that mix one object measured in
> > inches and another measured in centimeters should not occur
> > very often even in physics software and should be made as
> > explicit as possible.

I am totally out of context here, both because I'm not a physician and
because I've never had to deal with magnitudes and its units in software,
but I'll add the following comment anyway, at the risk of being naive or
plain wrong.

I was taught that you just can't mix different units of the same magnitude
in the same expression, you *have to* normalize all units of all magnitudes
into a particular unit system *before* evaluating the expression.

I think any units library should enforce this. Expressions should deal only
with a single fixed unit for every magnitude and conversion rules should be
supplied so the user can normalize the unit of magnitudes before operating.
I'm not sure how this could be mechanized, but I would like the system to
entirely disallow you to mix different unit systems, enforcing you to apply
explicit conversions if necessary.

I don't know if this is the way you physicians work in the real world, but I
surely hope so, since I've spent many years in high-school and university
being *forced* to apply this, so I got to believe it is the right way.

If the *only* problem with this approach is the numerical issues involved in
the conversion, then I think that it should be solved in itself, without
cluttering the library interface. In particular, I figure that in the case
of unit conversions, a rational representation should be enough to remove
the errors in the conversion.

Just my 2 cents.

Fernando Cacciola
Sierra s.r.l.

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