hash function

[Chris Torek]

>In article <14583 at dog.ee.lbl.gov> I wrote:
>>The [`why'] question is the hardest.  What *does* that 33 do?  I have no
>>idea. ...

In article <1991Jun26.112724.20539 at syd.dit.CSIRO.AU>
evans at syd.dit.CSIRO.AU (Bruce.Evans) writes:
>I don't think there are any theoretical mysteries behind the 33. 33 = 32 + 1.
>The 32 is to avoid mixing bits with previous hash bits. 256 would avoid all
>mixing (with 8-bit chars) but it would throw away too many bits. The 1 is to
>avoid throwing away bits.

This answer just does not hold up: if this were the case, 65, 129,
etc., should work as well as 33.  They do not.  Why not?

>The following hash function worked well for me in an assembler. ...
>   length = strlen(str); ... hashval = hconv(str[-1]) * MULTIPLIER;

At this point, str[-1] is unlikely to exist.  The function seems to
expect a pointer to the last character, rather than the first.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov