Boost logo

Boost :

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

> 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 Foster dean_at_[hidden]
Statistics, Wharton, U. Penn 215 898 8233
Philadelphia PA 19104-6302

Boost list run by bdawes at, gregod at, cpdaniel at, john at