2 added 93 characters in body
source | link

If all you know about the dataset is that it is a subset of the binary representations of the 5-combinations of 52, then there are 2598960 different possible potential values and the only way to avoid a collision is to assign each element to a distinct integer in a set of 2598960 different integers. That's isomorphic to a ranking algorithm, and provides for a hash of less than 22 bits.

Undoubtedly, if your dataset only contains a small substesubset of that universe, a smaller hash would be useful. Any perfect hash algorithm will work unmodified. You could run the perfect hash algorithm on the 22-bit rank rather than the 52-bit representation, but the possible gains are probably not sufficient to overcome the cost of computing the rank. And that is the best use you can make of your knowledge about the domain restriction.

I don't know anything about you application environment but it is quite possible that you could achieve better performance with a simpler hash function and an efficient hash table implementation. For example, for fixed datasets, cuckoo hashtables can guarantee that only two locations need to be examined in a find operation. To compute the two locations, two different hash functions are used but since the hash computations are completely independent, the two computations can be performed in parallel. That might be an improvement over the FNV algorithm. The cost of this guarantee is a maximum load factor of 0.5, which is a lot worse than the FNV algorithm, but might still be bearable for small datasets that might not be unbearable.

If all you know about the dataset is that it is a subset of the binary representations of the 5-combinations of 52, then there are 2598960 different possible potential values and the only way to avoid a collision is to assign each element to a distinct integer in a set of 2598960 different integers. That's isomorphic to a ranking algorithm, and provides for a hash of less than 22 bits.

Undoubtedly, if your dataset only contains a small subste of that universe, a smaller hash would be useful. Any perfect hash algorithm will work unmodified. You could run the perfect hash algorithm on the 22-bit rank rather than the 52-bit representation, but the possible gains are probably not sufficient to overcome the cost of computing the rank. And that is the best use you can make of your knowledge about the domain restriction.

I don't know anything about you application environment but it is quite possible that you could achieve better performance with a simpler hash function and an efficient hash table implementation. For example, for fixed datasets, cuckoo hashtables can guarantee that only two locations need to be examined in a find operation. To compute the two locations, two different hash functions are used but since the hash computations are completely independent, the two computations can be performed in parallel. The cost of this guarantee is a maximum load factor of 0.5, but for small datasets that might not be unbearable.

If all you know about the dataset is that it is a subset of the binary representations of the 5-combinations of 52, then there are 2598960 different possible potential values and the only way to avoid a collision is to assign each element to a distinct integer in a set of 2598960 different integers. That's isomorphic to a ranking algorithm, and provides for a hash of less than 22 bits.

Undoubtedly, if your dataset only contains a small subset of that universe, a smaller hash would be useful. Any perfect hash algorithm will work unmodified. You could run the perfect hash algorithm on the 22-bit rank rather than the 52-bit representation, but the possible gains are probably not sufficient to overcome the cost of computing the rank. And that is the best use you can make of your knowledge about the domain restriction.

I don't know anything about you application environment but it is quite possible that you could achieve better performance with a simpler hash function and an efficient hash table implementation. For example, for fixed datasets, cuckoo hashtables can guarantee that only two locations need to be examined in a find operation. To compute the two locations, two different hash functions are used but since the hash computations are completely independent, the two computations can be performed in parallel. That might be an improvement over the FNV algorithm. The cost of this guarantee is a maximum load factor of 0.5, which is a lot worse than the FNV algorithm, but might still be bearable for small datasets.

1
source | link

If all you know about the dataset is that it is a subset of the binary representations of the 5-combinations of 52, then there are 2598960 different possible potential values and the only way to avoid a collision is to assign each element to a distinct integer in a set of 2598960 different integers. That's isomorphic to a ranking algorithm, and provides for a hash of less than 22 bits.

Undoubtedly, if your dataset only contains a small subste of that universe, a smaller hash would be useful. Any perfect hash algorithm will work unmodified. You could run the perfect hash algorithm on the 22-bit rank rather than the 52-bit representation, but the possible gains are probably not sufficient to overcome the cost of computing the rank. And that is the best use you can make of your knowledge about the domain restriction.

I don't know anything about you application environment but it is quite possible that you could achieve better performance with a simpler hash function and an efficient hash table implementation. For example, for fixed datasets, cuckoo hashtables can guarantee that only two locations need to be examined in a find operation. To compute the two locations, two different hash functions are used but since the hash computations are completely independent, the two computations can be performed in parallel. The cost of this guarantee is a maximum load factor of 0.5, but for small datasets that might not be unbearable.