Re: [boost] Re: units library: A hash function approach type safe quantities

From: Dean Foster (foster_at_[hidden])
Date: 2001-10-02 10:30:09

> > I'm not sure I follow this bit.  Would one be able to talk about a
> > future price of sugar?  (say: future_dollars / lbs_sugar).
> 
> I don't see why not.  You're allowed to multiply and divide quanties
> with any units.  You're would not be allowed to say
> future_dollars+lbs_sugar.  future_dolars/lbs_sugar would have the
> dimensions of currency / weight, units of dollars / pound.  You can
> then apply your hashing idea to the sugar and future_dolars tags.  

But what I want to avoid is assigning a variable X of type
future_dollars/lbs_sugar variable to a variable Y of type
current_dollars/lbs_sugar.  Both would be in units of "dollars/lbs"
but are very different concepts.  BUT, I should be able to compute X/Y
and have it come out as future_dollars/current_dollars  (which would
have units of pure).  Likewise, Y/X should be
current_dollars/future_dollars.  X/Y should not interconvert with Y/X
inspite of both of them being of type pure.  I don't think this would
be possible by adding tags.  The problem is that we now have three
pure numbers:

        pure = truely pure
        pure = current_dollars/future_dollars
        pure = future_dollars/current_dollars

So it isn't just adding a single tag for each unit (like corn, sugar,
etc) but sometime even non-units need tags (like pure).

dean

=============================================================================
Dean Foster                                                   dean_at_[hidden]
Statistics, Wharton, U. Penn                                     215 898 8233
Philadelphia PA 19104-6302                 http://diskworld.wharton.upenn.edu