Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: hash function
Message-ID: <14735@dog.ee.lbl.gov>
Date: 27 Jun 91 12:28:24 GMT
Article-I.D.: dog.14735
References: <14491.28619071@stjhmc.fidonet.org> <14583@dog.ee.lbl.gov> <1991Jun26.112724.20539@syd.dit.CSIRO.AU>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 22
X-Local-Date: Thu, 27 Jun 91 05:28:24 PDT

>In article <14583@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@syd.dit.CSIRO.AU>
evans@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@ee.lbl.gov