Re: Quantity libraries: SIunits

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 
see.

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

1) In one library (e.g., SIUnits) the fundamental objects are 
"dimensions".
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.

So

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 
libraries?

If so, they're not really so different. A unit in the second library
is 
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? 

Deane

--- 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 
suggesting
> > 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 
standards
> 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 
sense
> to have a user-defined-units library.  For example, the code that 
I've
> 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, 
etc.
> But, I never want to add CPU-time to SI-time.  They are 
measuring
> different things and any code that wants to add them together 
is
> mostlikely incorrect.  If it is correct, then it should at least
> require a cast to draw attention to the fact that something weird 
is
> being done.  (Or more accurately multiplying by a conversion 
factor
> that might be CPU-time/SI-time, but on a 4 processor parallel 
machine
> the right conversion might be 4 CPU-time/SI-time.)
> 
> It might very well be that most applications fall either in the 
domain
> of hard core physics where SI does it all or fall well outside 
physics
> 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 
have
> two libraries or only one library.
> 
> dean
> 
> =================================================
============================
> Dean Foster                                                  
dean_at_f...
> Statistics, Wharton, U. Penn                                    
215 898 8233
> Philadelphia PA 19104-6302                 http://
diskworld.wharton.upenn.edu