[m-dev.] Re: pragma fact_table

Fergus Henderson fjh at cs.mu.oz.au
Wed Feb 26 19:31:26 AEDT 1997


Zoltan Somogyi, you wrote:
> 
> Before /home/staff running out space truncated my mail, I wrote:
> 
> > > +% Create a non-negative integer hash value for a float.
> > > +
> > > +:- pred float__hash(float, int).
> > > +:- mode float__hash(in, out) is det.
> > 
> > Delete "non-negative".
> > If the user wants a non-negative hash value, they can use int__abs.
> 
> I think David's approach is significantly less error prone, and

I think the main reason David's approach is less error prone is that
`mod' in Mercury computes remainder rather than modulus.

The documentation for mod says "modulus (or is it remainder?)".
The implementation calls "%".  The behaviour of "%" is not specified
by the current C standard, but on the machines we have ported
to it computes remainder, and the next C standard is going to mandate
this.

So I think we should fix our implementation of `mod',
add `rem', and clearly document them both.

> I don't know of any situation in which negative hash values are useful.

If you are hashing on N floats, then it is slightly more efficient to
just grab the bits, xor them all together, and then at the very end
take the modulus (that totals N xors, one remainder, and one absolute
value) rather than taking N absolute values, and xoring them all together
(that totals N xors, one remainder, and N absolute values).

Also to me it makes more sense concepually this way:  a hash value is
just a set of pseudo-random bits -- why should the sign bit always be zero?
Discarding the sign bit may also give you a slightly hash function
(especially if the sign bit for floats is at the same position as the
sign bit for ints -- then `-2.0' and `2.0' would hash to the same value.)

I think that if we fix `mod', then David's approach shouldn't be less
error-prone.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.



More information about the developers mailing list