Re: quantity libraries

From: Deane_Yang_at_[hidden]
Date: 2001-09-09 22:22:59

Dean,

Thanks for saying much more clearly what I've been trying to
say much less clearly. It is indeed the strong type checking feature
that is by far the most useful aspect of the quantity library.

I have to say that I am skeptical that a quantity library that
quietly and automatically converts inches into centimeters would
have saved the Mars lander. I think the fact that these two
units managed to encounter each other in the same place in the 
software could be a hint of deeper problems.

I am very interested in seeing what you've done.

Deane

--- In boost_at_y..., Dean Foster <foster_at_d...> wrote:
> 
> > > I just joined the list a day or so ago. 
> > Hi Dean, welcome to boost.  
> > - Michael Kenniston
> 
> Thanks for the kind introduction to boost.  I posted my library on
> yahoo with the name of units.zip.  As an academic, I'm used to
> receiving nasty referee's reports, so hopefully I'll be thick 
skinned
> about comments.  I thought I'd say a few things that I learned about 
a
> quantities library from using one for the past year.
> 
> In reading over the postings over the summer I think there are two
> different goals a quantities library could aspire to.  The first is
> the SI goal: avoiding crashing into Mars and all that.  The second 
is
> catching programming errors by making signatures of functions more
> useful.  I built my library assuming that the primary goal was the
> first one.  So I built in the ability to have inches, yards, rods,
> miles, meters, etc.  But when it came time to actually use it, I
> almost never gave explicit values.  So the first goal seemed to be
> less important than I originally thought.  
> 
> What turned out to be very important to me was the ability to have
> signatures of functions that were meaningful.  To achieve this goal 
it
> is very important for the quantities to be user defined.  Let me
> explain via example.
> 
> A physicist has nice concepts like length, weight, etc.  Obviously
> they need funding (lots of it in fact) so they also would want to 
have
> a unit to represent money.  For them, they would be happy with a
> single type called "dollars."  But now consider a trader on wall
> street.  They need not only dollar, but also yen, pounds, etc.  From
> their perspective all the fancy units of physics could be lumped
> together as a single unit called "physical unit".  So they would
> measure corn in dollars/physical unit, where physical unit would be 
a
> bushel, and gold in yen/physical unit, where physical unit in this
> case would be a Troy ounce.  This mixing up bushels (a measure of
> volume) and ounces (a measure of mass/weight) would case them almost
> no confusion.
> 
> But units can get even more divided than that.  A trader might want 
to
> have different sorts of dollars.  Not only is it important to
> differentiate current_dollars, from future_dollars, but bids might
> want to be separated from asks.  So there could be many different
> sorts of dollars.
> 
> In fact, the system that I use my units classes in has two sorts of
> time.  Both CPU time and wall clock time are different units.  Both 
of
> them are naturally measured in something called seconds, BUT these 
two
> different times measure different things.  
> 
> My point is that as far as making programs easy to read, the crucial
> goal of a quantities class is to make the signature of a function 
say
> what the function expects when it is called.  Thus you want as few
> different types as possible subject to the constraint that there
> sufficient types so that functions rarely have a useless signature.
> So my goal is to switch useless signatures like:
> 
> 	f(double a, double b, double c);
> 
> to:
> 
> 	f(Dollars a, Bytes b, Time c);
> 
> later,
> 
> dean
> 
> p.s. If it seems of enough interest I can move over my cvs directory
> and do a proper submission.  The Makefile probably only works under
> gnu/linux/g++.  Hopefully the code itself is more portable.  :-)
> 
> 
======================================================================
=======
> Dean Foster                                                   
dean_at_f...
> Statistics, Wharton, U. Penn                                     215 
898 8233
> Philadelphia PA 19104-6302                 
http://diskworld.wharton.upenn.edu