Re: Scheme style auto-resizing hashtable

[Jay Glascoe <jglascoe@jay.giss.nasa.gov>]

On Wed, 21 Oct 1998, Maciej Stachowiak wrote:

> Hmm, if the difference is that small, maybe it would help to keep the
> auxiliary data in a vector instead of an alist?
> 

yeah, but I like doing (car myhashtab) and seeing all of its vital
statistics.  One thing I can do is assume that the alist header will
always be in the same order as when it was created.  I could then
decompose the header much more quickly.

> Also: what limitations are you finding in the Guile hash functions?
> Just the fact that they need a prime range to work well?
> 

guile> (hash "drizzl" 123457)
76839
guile> (hash "drazzl" 123457)
76839
guile> (hash "drapzl" 123457)
76839
guile> (hash "drapzo" 123457)
76839

Also, I'm storing the hash value in each entry (for efficient resizing),
so I want the hash to be a full long integer (scm_num2long(hash, "bif",
"baf")) in size.  I don't want the hasher to mod out by a number.  If I
wanted that, then I'd just do the modding myself.

> >  Would anyone knowledgeable about bit twiddling be willing to write
> > a Guile hasher that doesn't mod out by a given number?
> 
> Time to whip out _The_Art_of_Programming_ ...
> 

hrmmm.  Maybe I should buy that myself.

	Jay
	jglascoe@jay.giss.nasa.gov