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

From: Eric Ford (eford_at_[hidden])
Date: 2001-10-01 16:40:40

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

Ok.  The good thing about SI is that it defines a basis for "physical"
measurements.  Still it does have some short comings.  Money is an
obvious non-physical dimension that people are interested in.  However
for reasons previously discussed, I think a monetary library might
should be done separately.  It would be nice if they could interface.  

So for SI dimensions (maybe plus a few extras like currency), we can
form a basis of basic dimensions that users won't need to add to.
Users could add their own units for quantites with dimensions formed
from that basis of dimensions.  If you're worried about users
specifying units like seconds of cpu time on a Alpha 333, then I think
that could be addressed by tags on basic units.  

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

As small as possible without having too few.  I guess I don't see a
problem with having 16 or so integers.  As long as there's a good
notation, it shouldn't be cumbersome.  Compile time rationals makes it
appear as half as many template arguments.  Some typedefs and a class
that includes a typedef for the product of units provided as template
parameters, and you're set.

> >  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 are many more than 100 units.  I do beleive that we can form a
basis set for dimensions with much less than 100 basis elements.

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

Remember you have to allow for any rational power of basic units,
too.  Sure collisions won't happen all that often for sufficiently
large hash.  But's what the advantage of this way for SI units where
we do know of a basis.   I do see an advantage for user defined units,
where there are too many to anticipate.

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

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.  

E