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