Boost logo

Boost :

From: Deane_Yang_at_[hidden]
Date: 2001-09-13 16:39:13

I found both Walter's and Dean's messages very enlightening.
I would like to second Dean's views and try to describe what I

It does appear that two different libraries are being asked for:

1) In one library (e.g., SIUnits) the fundamental objects are
A dimension is a physical concept such as mass, time, length,
volume. Associated with any dimension are different units for
measuring that dimension.

The user wants the strong type checking to catch inconsistent
use of different dimensions in algebraic expressions and
function calls, but if the dimensions are consistent and different
units are used, implicit conversions are done automatically. So,
for example,

seconds = centimeters / (miles per hour)

is OK.

Since physical dimensions are emphasized, almost everything
is predefined.

2) In the other library, the fundamental objects are quantities
measured with respect to a specific unit. There is no concept of
"dimension" assumed. Therefore, there is no implicit conversion
between different units provided by the user; "casting" between
different units should be defined explicitly by the user.

A user of this library wants to use the strong type checking
to catch errors in formulas and function calls that use different
units (and derived units obtained through ratios, products, and
powers of existing units) inconsistently.

There is no built-in concept of "dimension"; the user can build
that on top of the library.


seconds = centimeters / (centimeters per second)

is OK, but

seconds = centimeters / (miles per hour)

is not.

This library would not have any predefined units.

Does this accurately reflect the difference between the two

If so, they're not really so different. A unit in the second library
really just a new "dimension" with only one possible unit defined.

However, I still see the second library as more fundamental; all it
does is define the notion of a unit (actually there are two kinds:
absolute units and relative units), of a derived unit through ratio,
product, or power of existing units, and of allowable algebraic
operations combining different units (not conversion. rather,
things like unit1 * (unit2/unit1) = unit2). There would be no
predefined units.

The second library would predefine all the SI units and group
units together according to the different dimensions. It would
also provide conversions between the different units for the
same dimension.

Outside of physics, I don't see much need for automatic
conversion between different units that measure the same
quantity. Honestly, I'm still puzzled why it is needed in physics
software. I can only think of two reasons why you would mix
inches and centimeters in the same software:

1) You want to provide an interface that allows either unit.
But then wouldn't you still want the implementation to use a
single consistent unit, so wouldn't you just immediately explicitly
convert the input into the right units? And wouldn't you want the
conversion to be explicit, so the internal use of a consistent unit
is clearly documented?

2) There are two different modules, one where inches are more
convenient or natural and another where centimeters are better.
Then there is another module that interacts with both modules.
Again, wouldn't you want the conversions to be made explicit?

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. And I can't conceive of any circumstances
where I would want

seconds = centimeters / (miles per hour)

to compile without any complaint. Could someone explain to me
why this is unreasonable or just plain wrong?


--- In boost_at_y..., Dean Foster <foster_at_d...> wrote:
> >
> > X-eGroups-From: wb_at_f... (Walter Brown)
> >
> > Adding new quantities, too, is useful. However, you are
> > adding a new quantity that requires adding a new
"dimension" first. I
> > understand what you are proposing, but the International
System of
> > Units does not provide any guidance in this direction.
> >
> I certainly like the adherance to standards. Fruther the SI
> have been fairly well thought out. So it does make sense to
have a
> pure SI-units library. I guess I'm argueing that it also makes
> to have a user-defined-units library. For example, the code that
> been working on needs the following units:
> CPU-time (a clock that stops when paged out)
> SI-time (this would be a SI)
> byte (unit of information--I think this is non-SI)
> dollar (unit money)
> I'll then use derived units like dollar/byte second, dollar/CPU,
> But, I never want to add CPU-time to SI-time. They are
> different things and any code that wants to add them together
> mostlikely incorrect. If it is correct, then it should at least
> require a cast to draw attention to the fact that something weird
> being done. (Or more accurately multiplying by a conversion
> that might be CPU-time/SI-time, but on a 4 processor parallel
> the right conversion might be 4 CPU-time/SI-time.)
> It might very well be that most applications fall either in the
> of hard core physics where SI does it all or fall well outside
> that so that few of the SI units would be useful. This would
argue for
> creating two entirely seperate libraries.
> So the question in my mind isn't whether these two
programming styles
> are both important (I beleive they are) but whether we want to
> two libraries or only one library.
> dean
> =================================================
> Dean Foster
> Statistics, Wharton, U. Penn
215 898 8233
> Philadelphia PA 19104-6302 http://

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