I already have a 64 bit hash function in a library (C coding), but I only need 48 bits. I need to trim down the 64 bit hash value to a 48 bit value, yet it has to be in a sa
hash >>= 16;
But if you feel better arbitrarily preserving the other 16 bits just use XOR.
hash = (hash >> 16) ^ (hash & 0xFFFF);
If the 64-bit hash is good, then selecting any 48 bits will also be a good hash. @Lee Daniel. Of course, information is lost and not reversible.
unsigned long long Mask48 = 0xFFFFFFFFFFFFu;
unsigned long long hash48 = hash64 & Mask48;
If 64-bit hash function is weak, then mod by the largest prime just under pow(2,48)
. Some buckets will be lost. This will not harm a good hash, yet certainly make weak hashes better.
unsigned long long LargestPrime48 = 281474976710597u; // FFFFFFFFFFC5
unsigned long long hash48 = hash64 % LargestPrime48;
There exist no 48-bit hash algorithms as far as I know. Neither do 48-bit variable types exist, so this is a very strange design choice anyway.
And of course you can't shorten a 64-bit hash down to a 48-bit without loss and safe hashing is a completely different topic anyway. You could do something like using a common 32-bit hash function like CRC32 or so and just have 16 empty bits. Or even combining a 32-bit and 16-bit but that seems really really odd. From a collision-safe standpoint this isn't even a thing and I wouldn't want to hear the response of a cryptologically experienced person on this.
My recommendation: Use standard sized established hashing algorithms and don't make experiments. It's already hard enough to come up with a good hashing algorithm anyways. There's no need to become creative except you're an expert on your field and can handle the effects the change may have (which is probably the most difficult part).