Re: units library: A hash function approach type safe quantities

From: Eric Ford (eford_at_[hidden])
Date: 2001-10-01 13:33:14

I attempted to post a more lengthly reply to this, but it seems it
didn't come through.  I'll be brief this time.  If the other message
never does come through I can elbaorate later, if people ask for
clarification on some parts.

> What makes this totally ugly is that if you want 10 different units,
> you have 10 template integers.  Not only is the code unreadable, but
> to use 12 different units instead of 10 is almost impossible without
> learning sed first!
>...
> and similarly for Ratio_of_units.  Thus our final code would look
> something like:
> 
> typedef Unit< 0       >    pure;
> typedef Unit< h_foot  >    foot;
> typedef Unit< h_pound >    pound;
> typedef Unit< h_second>    second;
> typedef Product_of_units<foot,pound> foot_lbs;
> typedef Ratio_of_units<foot,second>  feet_per_second;

I don't understand your complaint about a list of rationals.  Is it
readability?  It seems typedefs similar to these could be applied to
that system as well.  

>   o Is there a way of automatically generating good hash values for
the
>     basic units?  Something close to random would be ideal.  If we
can't
>     do the modulo arithmetic they have to be kinda small though. 
(say
>     around 10-100 Million of a typical machine with 2^31 being the
maximum
>     signed value.)

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).  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).  This guarentees no collisions for a_i's <
b, and for b = numeric_limits<unsigned int>::max(), this is equivalent
to just a list of unsigned int's.  So we're back to a long list of
integers. 

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

E