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

From: Dean Foster (foster_at_[hidden])
Date: 2001-10-01 15:11:09

E wrote:

> I don't understand your complaint about a list of rationals.  Is it
> readability? 

No, it is a matter of extensibility.  If you hardwire in the number of
basic units you have, rest assured, someone will find a situation
where they need more!  So I'm trying to avoid hard-wiring in that
information. 

> In the case of the SI dimensions, we have apriori knowledge that I
> think we can use to our advantage.  It seems like the optimal hash
> function and transformation would avoid collisions for small integers
> (in both the numerators and denominators). 

Yup.  I agree.  I'd add further that the total of the integers should
be small.  This is where a win is possible.

>  Yet that seems suspicously
> close to writing a number as a_0 + a_1 * b^1 + a_2 * b^2 +... a_n *
> b^n, where a_0 is in [0,b). 

Again right--this could be used to mimic the existing SI like code.
To make it clear, supposed b is 10:

typedef Unit<   0 >    pure;
typedef Unit<   1 >    foot;
typedef Unit<  10 >    pound;
typedef Unit< 100 >    second;
typedef Unit<  11 >    foot_lbs;   // 1 + 10
typedef Unit< -99 >    feet_per_second;  // 1 - 100

But what I'm proposing is something closer to:

typedef Unit<   0 >    pure;
typedef Unit< 133 >    foot;
typedef Unit< 127 >    pound;
typedef Unit< 101 >    second;
typedef Unit< 260 >    foot_lbs;  // 133 + 127
typedef Unit<  32 >    feet_per_second; // 133 - 101

then there could easilly be lots of different units of with their has
close to 100.  There will be strange combinations that will hash to
the same place:

        hash(foot^5/sec^8) = hash(sec^9/(lbs^2*foot^6))
        
but this shouldn't occur very frequently.  So the advantage of the
other scheme is that it guarentees no collisions for reasonable
values, whereas my scheme might have a few collisions.

> In the case of basic units (e.g. meter, kilogram) with tags (of yarn,
> of sugar), a hash system might be more useful, since there we don't
> have much a priori knowledge of the unit tags which will be used. 
> There could be many of these which can't be combined in rational
> powers like SI units can.  So extending the SI units framework to
> allow for lots of such unit tags might cause large compile times with
> no advantage. 
> 
> Each unit tag could contain a list of the hashes of other unit tag's
> which it can be converted to (e.g. a pound of brown sugar can be added
> to a pound of white sugar to give two pounds of sugar).  

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

> E

dean

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