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

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

> > What about assigning a different prime number to each dimension,
and
> > representing multiplication of units as multiplication of the
associated
> > primes? 
> 
> This would be great espicially if we could work mod-a-prime.  Using
> the GCD I think we can find the multiplicative inverse mod-a-prime.
> Then division can be represented also.  I don't think you get unique
> factorizations when working mod-a-prime.  So it still only provides
> limited protection.  But good enough to prove that most illegal
> conversions would be caught with high probability.

You'd want to choose a set of numbers that are relatively prime in
that modulus arithmetic.  However, if a is one of your numbers, than
a^n=1 for some n and therefore a^(n-m) = a^m.  Given that you'll need
to find several numbers that are all relatively prime to each other,
this can happen pretty soon.

> > It also solves the decomposition problem (extracting the basic
units and
> > their exponents from a composite unit), which I suspect may be a
> > showstopper for your addition-of-hash-values approach.
> 
> I wasn't planning on providing any way of extracting basic units
from
> the hash values.  Should these be desired, probably a trait class
> could be added to compute them.  But I don't think it is actually
> important to be able to do.  These ARE compile time classes, so it
> isn't as if we need to dynamically figure out the units.

I think that would be important.  For example, how to you convert
between two quantites of the same dimensions but different units, when
you know the conversions for all the basic units?  Or how to you know
what to print as the units beside the value?

E