14,028,097 members
alternative version

#### Stats

32.1K views
54 bookmarked
Posted 15 Jan 2018
Licenced CPOL

# A New Hash Function - ZobHash

, 25 Jan 2018
Can we write a new better hash function?

## Introduction

I think most of the existing hash functions were developed many years ago, by very smart people. It is probably not possible to improve hashing algorithms any longer, still, I had to try this idea below.

## Background

But first, as you know, a hash function is a function that converts any data of any size to a fixed sized number. It is widely used in, e.g., lookup tables.

In a previous article of mine, on chess engine programming1, I learned a very cool hashing technique for chess board states. Zobrist hashing5 proved to be able to give an almost unique hash code for every chess position in a game, even though there are almost infinitive states a chess game can be in. I think that we can use Zobrist algorithm to hash for example something more common like words. Results revealed at the end. (It worked!)

As you probably know, .NET already contains a hash function for `string`s. The method is called `GetHashCode` and it converts any object to an integer.

I want to know if we can create a better function using Zobrist ideas and with less collisions.

## Hash Collisions

A hash collision occurs when two different objects, in this case `string`s, result in the same hash code.

I'm using a list of 466,545 English words3. The function `GetHashCode` in .NET produces only 48 collisions on this data set, so it is probably good enough in most scenarios. If you are fine with 48 collisions, you don’t have to read on. Here are few examples of words with same .NET hash code.

• furnaces ferrate
• matinee cistronic
• toeholds argon
• unsmart pulped

You might argue that since the dataset is known, it would be very easy to create a perfect hash algorithm without collisions. We could just give each word its unique number.

However, that is not the purpose of this investigation. We want the hash function to work for any word in any language and with a very low probability of collisions.

## Zobrist Hash

Zobrist hashing works by bit-wise XOR-ing random numbers. In a chess engine, random numbers are generated for moves, and a move is defined by removing a piece from a square and then putting it on another.
There are two player colors, six piece types and 64 squares. 2 * 6 * 64 = 768 random numbers.
(Not taking into account castling and enpassant, but you get the point.)

When hashing words, I thought that we can generate random numbers for each character and then do the same thing as in Zobrist hashing. One bit-wise XOR operation for every character in a word.

```public static int ZobHash(this string text)
{
var hash = ZobRandom.Start;
foreach (var c in text)
hash ^= ZobRandom.Numbers[c];
return hash;
}```

But when doing this, I get 218,163 collisions. Not very encouraging, but instead of giving up, let’s look at why there are so many collisions.

Here are a few examples:

• abied abide
• abiegh abeigh
• acidly acidyl
• acron acorn

As you can see, Zobrist hash gives the same hash code for words independent of the order of the letters, i.e., the order of the XOR operations.
That is how XOR works and it's perfect for storing chess game states, because the order of moves that led to a board position doesn’t matter, it is still the same game state. But for hashing of words, it does not work.

## Improve Zobrist Algorithm

Let’s try to extend Zobrist hash so the order of the letters also affects the resulting hash code.
What if we try to do a cyclic bit-shift (very fast operations) for each character random number?
A cyclic bit shift pushes the bits in a number to the left (or to the right if you want) like this:

 When the number 153, which is binary 10011001 is cyclically shifted to the left, the result is 00110011 and when you push it two times (next char) 01100110

This is the function for cyclic left bit shift.

```private static uint RotateLeft(uint value, int count)
{
var r = count % 32;
return (value << r) | (value >> (32 - r));
}```

And the final hash function looks like:

```public static uint ZobHash(this string text)
{
var hash = ZobRandom.Start;
var i = 1;
foreach (var c in text)
hash ^= RotateLeft(ZobRandom.Numbers[c], i++);
return hash;
}```

## Random Seeds

As I mentioned above, Zobrist hash uses a list of random numbers. For some reason, the function works better with some random numbers.
You might be unlucky to select a bad random seed that in the end generates more hash collisions.
So, implementing a Zobrist hashing function is also about selecting a good random seed.

## The Results

Below is the result of counting performance and number of collisions for the list of 466,545 unique English words.
Also comparing with a few other hash functions from Brandon Dahler nuget System.Data.HashFunction4.
If you have a suggestion on more hash functions we should compare with, please comment below.

These are the results from hashing byte-arrays.

Functions with 32-bit hash codes:

 Function 106 Words/s Collisions ZobHash 4.67 5 GetHashCode .net 7.52 1592 JenkinsOneAtATime 3.99 36 BernsteinHash 4.57 343 CRC 3.17 23 ELF64 4.32 4347 JenkinsLookup2 3.67 23 JenkinsLookup3 3.64 30 ModifiedBernsteinHash 5.69 320 MurmurHash1 3.86 27 xxHash 3.15 16 Djb2 5.55 344

Functions with 64-bit hash codes:

 Function 106 Words/s Collisions ZobHashLong 5.3 0 FNV1 3.24 0 FNV1a 3.11 0

These are the results from hashing `string`s (a lot faster without conversion to byte-array):

 Hash function 106 Words/s Collisions ZobHash 24.6 5 ZobHashLong 25.9 0 GetHashCode .net 51.8 48

## Conclusion

ZobHash performs well compared to all tested functions. For functions that generate 32-bit hash codes, it has the lowest rate of collisions. There are functions that are faster, but they produce more collisions.
Interestingly .NET `GetHashCode` gives different number of collisions depending on if you hash a byte array or a `string`.

For 64-bit hash code functions, none of the tested functions generates collisions but ZobHash is the fastest.

That was all for now and don't forget to vote!

Thanks!

## History

• January 16, 2018 - Version 1.0.0
• January 19, 2018 - Version 1.0.1
• Fixed a bug on right shift for `int`s. Changed `int` to `uint`
• Added simple implementation in C

## Share

 Software Developer (Senior) Sweden
No Biography provided

## You may also be interested in...

 First PrevNext
 good Member 1400182729-Sep-18 1:14 Member 14001827 29-Sep-18 1:14
 Hash Function Member 1391942919-Jul-18 23:18 Member 13919429 19-Jul-18 23:18
 Re: Hash Function KristianEkman2-Sep-18 6:16 KristianEkman 2-Sep-18 6:16
 Hash Function Member 1391942919-Jul-18 23:17 Member 13919429 19-Jul-18 23:17
 Provide a link for Zobrist hashing RenniePet21-Jan-18 18:52 RenniePet 21-Jan-18 18:52
 Re: Provide a link for Zobrist hashing KristianEkman22-Jan-18 0:20 KristianEkman 22-Jan-18 0:20
 Table Searching Rick York19-Jan-18 5:06 Rick York 19-Jan-18 5:06
 Re: Table Searching KristianEkman19-Jan-18 8:08 KristianEkman 19-Jan-18 8:08
 small error in C implementation armando bouza19-Jan-18 2:19 armando bouza 19-Jan-18 2:19
 Re: small error in C implementation KristianEkman19-Jan-18 8:04 KristianEkman 19-Jan-18 8:04
 useful for integrity check armando bouza19-Jan-18 0:32 armando bouza 19-Jan-18 0:32
 Re: useful for integrity check KristianEkman19-Jan-18 0:41 KristianEkman 19-Jan-18 0:41
 Re: useful for integrity check armando bouza19-Jan-18 2:59 armando bouza 19-Jan-18 2:59
 finding a collision in your hash and crc Dismember18-Jan-18 8:09 Dismember 18-Jan-18 8:09
 Re: finding a collision in your hash and crc KristianEkman18-Jan-18 8:28 KristianEkman 18-Jan-18 8:28
 Random factor in hash function peixaxo18-Jan-18 5:31 peixaxo 18-Jan-18 5:31
 Re: Random factor in hash function KristianEkman18-Jan-18 5:50 KristianEkman 18-Jan-18 5:50
 Re: Random factor in hash function Member 1232497918-Jan-18 8:51 Member 12324979 18-Jan-18 8:51
 Re: Random factor in hash function KristianEkman18-Jan-18 9:33 KristianEkman 18-Jan-18 9:33
 Re: Random factor in hash function 42Bastian18-Jan-18 10:06 42Bastian 18-Jan-18 10:06
 Re: Thanks for inspiration KristianEkman18-Jan-18 5:53 KristianEkman 18-Jan-18 5:53
 You can strengthen it as follows ... Member 1330167918-Jan-18 3:06 Member 13301679 18-Jan-18 3:06
 I've actually used this before to perform quick string searching on a 16m word corpus. I did not use a table of random mappings to provide a smooth distribution. Instead I shifted the current hash 1 bit left before XORing the new character and ignored the shift-in on the right. This speeds things up a great deal because out of two shifting operations you get rid of half of them, and doesn't affect the probability distribution of the result. The other reason for doing so is because the shifting-in of the carry bit on the right is only cheap in cycles when your hash value is a multiple of 8-bits. When using 11-bit hashes (like I was doing) you have to mask off bit-12 after shifting left and then add it in on the right. These are an extra 8-12 instructions compared to the single rotate instruction. (There was a good reason for me to use an 11-bit hash: it give me 2048 possible values, so I simply appended each string (pointer) to one of 2048 arrays based on what the hash value was. If the hash was zero, the string was appended to the end of array[0], if the hash was one, then it went onto the end of array[1], etc. I used the remainder of the bits (12-32) to record the position of the string in the array, hence each string could have a unique ID of 21+11 = 32 bits. When a new string was searched for I could calculate the 11-bit hash and perform a linear search on the contiguous memory for that array. Very very fast, especially since the contiguous memory meant that the string being compared was already in the cache when performing the linear search).
 Re: You can strengthen it as follows ... KristianEkman18-Jan-18 4:41 KristianEkman 18-Jan-18 4:41
 Possible error Per Øyvind18-Jan-18 2:16 Per Øyvind 18-Jan-18 2:16
 Last Visit: 21-Apr-19 3:07     Last Update: 21-Apr-19 3:07 Refresh 12 Next »