Question about Zobrist code

[Hamfer]

Zobrist codes are randomly generated and engine must work the same manner whatever the values are.
For Robbolito, if you modify the value affected to zobrist_move_white (for example) :
zobrist_move_white = RAND64(); by zobrist_move_white = 0x1A1C884F4AA29F6EULL;
the behaviour change.

What is the explanation ?

Sorry for my bad english.

[User923005]

This is the explanation of how Zobrist hashing works, right from the horse's mouth:
http://research.cs.wisc.edu/techreports/1970/TR88.pdf

Once the program has started up, the hash codes should not be changed. However, at initialization, they can be set to any linearly independent combination of hash values. In other words, if you have the same value in the table twice, bad things will happen.

You might wonder why some programs do not use static values that have been precomputed. That would be nice, on one hand because you can reproduce and debug problems more easily. But if you change them at program startup, then the program will have the same strength every time it plays, but the search tree will be slightly differently shaped and this will make the program play a little bit differently. The advantage of this is that other programs cannot as easily lay an ambush for your program by preparing an opening against your engine because it will choose slightly different moves from time to time.

A similar thing could be said for Stockfish's blocky evaluation. It considers (for instance) two positions that differ by only 4 centipawns as having the same evaluation. This also introduces a tiny bit of randomness in game play and also makes the search run a bit faster which is a double benefit.

[Hamfer]

I know how Zobrist hashing work. Of course, I know if you change the value of one element, the total hash change.
What I say is: the BEHAVIOUR of Robbolito change, ie analysing the same position at the same depth with different value of, say, zobrist_move_white affect the number of nodes and pv line.

[User923005]

I know how Zobrist hashing work. Of course, I know if you change the value of one element, the total hash change.
What I say is: the BEHAVIOUR of Robbolito change, ie analysing the same position at the same depth with different value of, say, zobrist_move_white affect the number of nodes and pv line.

Sure, the tree is very sensitive to tiny changes. It will analyze some positions faster and some positions slower if you make any tiny changes.
The overall performance of the engine will not change by a measurable amount over a large number of games, though.

The same thing will happen with any other chess engine. Try some experiments and see.

[syzygy]

What I say is: the BEHAVIOUR of Robbolito change, ie analysing the same position at the same depth with different value of, say, zobrist_move_white affect the number of nodes and pv line.

This is because the positions stored in hash will be overwritten at different times depending on the actual set of Zobrist values.

If you take two positions A and B that map to the same entry or bucket of the hash table with one set of Zobrist values, then they will most likely map to different entries or buckets with another set of Zobrist values. So with the first set of values, A might be overwritten when storing B in the table, while with the second set of values not A but some other position will be overwritten when storing B. Now when the search at some later time probes position A, the behaviour will be different.

[User923005]

What I say is: the BEHAVIOUR of Robbolito change, ie analysing the same position at the same depth with different value of, say, zobrist_move_white affect the number of nodes and pv line.

This is because the positions stored in hash will be overwritten at different times depending on the actual set of Zobrist values.

If you take two positions A and B that map to the same entry or bucket of the hash table with one set of Zobrist values, then they will most likely map to different entries or buckets with another set of Zobrist values. So with the first set of values, A might be overwritten when storing B in the table, while with the second set of values not A but some other position will be overwritten when storing B. Now when the search at some later time probes position A, the behaviour will be different.

What an excellent response, I wish I had penned it.

In addition to that, two different hash sets can have slightly different collision rates because of hamming distance differences, etc.
An ideal set would have perfectly independent hash codes for each field obtaining a hash value that is not a linear combination of any collection of the other values (or near to it, bit-wise).
I created an extremely independent set some time ago {maximizing the hamming distance over the entire set}, but I doubt it would have any significant impact on the playing strength of a program.

[Don]

What I say is: the BEHAVIOUR of Robbolito change, ie analysing the same position at the same depth with different value of, say, zobrist_move_white affect the number of nodes and pv line.

This is because the positions stored in hash will be overwritten at different times depending on the actual set of Zobrist values.

If you take two positions A and B that map to the same entry or bucket of the hash table with one set of Zobrist values, then they will most likely map to different entries or buckets with another set of Zobrist values. So with the first set of values, A might be overwritten when storing B in the table, while with the second set of values not A but some other position will be overwritten when storing B. Now when the search at some later time probes position A, the behaviour will be different.

What an excellent response, I wish I had penned it.

In addition to that, two different hash sets can have slightly different collision rates because of hamming distance differences, etc.
An ideal set would have perfectly independent hash codes for each field obtaining a hash value that is not a linear combination of any collection of the other values (or near to it, bit-wise).
I created an extremely independent set some time ago {maximizing the hamming distance over the entire set}, but I doubt it would have any significant impact on the playing strength of a program.

I remember Bob Hyatt used to be big on minimizing the hamming distance but that was a long time ago. But there was a long discussion on this on one of the forums and we all came to the conclusion that it was a lot of work for nothing. I think I had asked Bob about it and his advice was that it was a waste of time. As long as you have a strong random number generator you should have no problem at all. I'm not even sure it has to be that strong but it sure doesn't hurt. There are probably some weak generators that would be fine and others that would be horrible for this particular thing.

[hyatt]

Burton Wendroff wrote an ICGA paper on this very topic, dealing with random numbers, zobrist hashing, and "protection". The deeper we go, the more zobrist randoms get xor'ed together to alter the signature, and things go wrong. The main thing is to avoid keys that are identical, obviously. Beyond that, it is likely a waste of effort since xoring a long string of randoms can produce a value of "0" on occasion, which would be a problem. And there seems to be no way to actually work around that problem given today's depths.