Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Good hash for pointers
Date: Mon, 3 Jun 2024 22:41:00 +0300
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <20240603224100.00003ea1@yahoo.com>
References: <v2n88p$1nlcc$1@dont-email.me>
	<v2qm8m$2el55$1@raubtier-asyl.eternal-september.org>
	<v2qnue$2evlu$1@dont-email.me>
	<v2r9br$2hva2$1@dont-email.me>
	<86fru6gsqr.fsf@linuxsc.com>
	<v2sudq$2trh1$1@raubtier-asyl.eternal-september.org>
	<8634q5hjsp.fsf@linuxsc.com>
	<v2vmhr$3ffjk$1@raubtier-asyl.eternal-september.org>
	<86le3wfsmd.fsf@linuxsc.com>
	<v2voe7$3fr50$1@raubtier-asyl.eternal-september.org>
	<86ed9ofq14.fsf@linuxsc.com>
	<v2vs40$3gflh$1@raubtier-asyl.eternal-september.org>
	<86sexypvff.fsf@linuxsc.com>
	<20240602104506.000072e4@yahoo.com>
	<v3kk9p$3u8qu$1@raubtier-asyl.eternal-september.org>
	<20240603174604.000014d4@yahoo.com>
	<v3kovm$3v2ie$1@raubtier-asyl.eternal-september.org>
	<v3kqo3$3v9m2$1@dont-email.me>
	<20240603201646.0000319d@yahoo.com>
	<v3l35r$ig0$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 03 Jun 2024 21:41:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9053c0190b599625b3548cfb8a0ee46e";
	logging-data="39740"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX190ZgDBplKX1NGqK2Mc9EfRFxd1YTkTBKg="
Cancel-Lock: sha1:T07gKoV2uJuSNRZsYl/6EPO9rMs=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 2914

On Mon, 3 Jun 2024 19:48:29 +0100
bart <bc@freeuk.com> wrote:

> 
> I don't remember seeing that anywhere. But, bucket_size is the size
> of the hash-table?
> 

Yes

> And Hash_max+1 is likely to be a power of two?
> 

Yes. At very least 2**32.

> I prefer my hash values to be evaluated independently of table size. 
> They usually don't have a meaningful maximum value, other than the 64 
> bit of their type, and I'd rather they didn't have sequences of zero 
> bits especially at the bottom end.
> 

Bottom is in the eye of beholder :-)

> If hash_max was 2**63-1, 

63 was my mistake. He suggests 2**64-1. It seems.

> say, then dividing by hash_max+1 would
> probably give you zero anyway, especially if you first multiplied by
> a bucket size that was a power of two, as all the interesting bits
> would disappear past the top bit!

Huh?
If bucket size is 2**n then 
index = Hash(key)*2**n/2**64 == Hash(key) >> (64-n);

May be, you are thinking about C language arithmetic? That not what I
had in mind. In post above I used equations in their integer math
meaning rather than integer C arithmetic meaning.