Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!limbo!taylor
From: taylor@limbo.Intuitive.Com (Dave Taylor)
Newsgroups: comp.mail.elm
Subject: Re: Aliases File
Message-ID: <1423@limbo.Intuitive.Com>
Date: 1 Nov 90 21:02:18 GMT
References: <1990Oct30.190327.26105@ux1.cso.uiuc.edu> <1663@chinacat.Unicom.COM> <sandrock.657397776@aries>
Reply-To: taylor@limbo.Intuitive.Com (Dave Taylor)
Organization: Intuitive Systems, Mountain View, CA: +1 (415) 966-1151
Lines: 45

Mark Sandrock asks:

> Not that it's a major deal, but it might be of some help to have an idea 
> why 251 was made the default. I use only a few aliases myself, and I 
> wonder how this value of 251 was derived?

Most hashing algorithms have better performance (e.g. less collisions)
when the hash table size is a prime number.  After having decided on a
particular hashing scheme for Elm I then ran a number of experiments 
with different sizes to ascertain whether it held true for the Elm 
alias scheme too.  It did.

Weird, eh?  :-)

Note that the hashing algorithm itself is pretty basic too; the hash
key is the sum of the ASCII values of the letters in the key:

	int
	hash_it(string, table_size)
	char *string;
	int   table_size;
	{
		/** compute the hash function of the string, returning
		    it (mod table_size) **/

		register int i, sum = 0;
		
		for (i=0; string[i] != '\0'; i++)
		  sum += (int) string[i];

		return(sum % table_size);
	}

(from Elm/src/aliaslib.c)

I would encourage people to retrofit a non-hashing algorithm if the
disk/memory space is a problem; it should be quite straightforward
to do so, especially if the current version still has the external
nameserver hooks in it...

						-- Dave Taylor
Intuitive Systems
Mountain View, California

taylor@limbo.intuitive.com    or   {uunet!}{decwrl,apple}!limbo!taylor