hash collisions

[Ovyron]

Last one with a full year of usage was Stockfish 10, you have a list of actual real bugs and how they were dealt with?

Here's a list of all changes from Stockfish 10 to Stockfish 11:

https://github.com/snicolet/Stockfish/c ... 4fb9703583

The fact of life is that Stockfish 10 was shipped with many bugs that were fixed between versions, and Stockfish 11 was shipped with many bugs that will be fixed between versions 11 and 12.

Because, if you paid attention to the scene, you'll see these releases had nothing special about them (there's no "bugless, stable version for release" to separate it from some "nightly, experimental version", all are experimental), other than some 50 ELO increase minimum that they set, not caring about the bugs (which are discovered and fixed as soon as possible.)

Every day that a bug is reported and fixed in a commit since Stockfish 11, it was a bug that was shipped with Stockfish 11, other than bugs introduced in new code and fixed in a short time frame, the rest have been there for a while.

[D Sceviour]

It has not been suggested here yet, but a consideration to look at for hash collision testing is the Hamming Distancehttps://www.chessprogramming.org/Popula ... gDistance .

Some programs like Crafty and Fruit use preset hash keys, but other engines are generating random numbers for every new instance of their engine. If the hamming distance of the zobrist keys are zero, then there is a likelihood of hash key failure, especially with lock-less hashing. This can be tested with:

hamming distance = popcount(a ^ b);

[chrisw]

Have you been smoking something bad? You seem no longer be able to distinguish me from Bob. It was not me who argued about the 100% bug-free. I even pointed out that my engine is.

If you didn't already have the reputation of being totally detached from reality, your performance in this thread would have convinced any reader of it in one big swoop. You don't seem to be able to grasp what people write, and who writes what. When I say I consider it important for efficiency to search impossible line, and explain preciely why I consider that better, you interpret it as that I don't care to 'fix' it...

Are you too stupid or doped to understand plain English, are you a compulsive liar who obsessively twists other peoples words, or what?

Rule One of Insulting. The insulter is almost always projecting his own behaviours. I don’t know what you get up to in Amsterdam, but you surely have been making up a bunch of suppositions and falsely attributing them.

I simply point out my input here is that chess engine mechanics are quite trivial and 100% bug free is entirely possible, it just takes good attitude by programmers. QC, testing and good management will do the rest. Bad attitude is finding reasons to argue that bugs are inevitably present no matter what.

[chrisw]

Last one with a full year of usage was Stockfish 10, you have a list of actual real bugs and how they were dealt with?

Here's a list of all changes from Stockfish 10 to Stockfish 11:

a change list is not a bug list

https://github.com/snicolet/Stockfish/c ... 4fb9703583

The fact of life is that Stockfish 10 was shipped with many bugs that were fixed between versions, and Stockfish 11 was shipped with many bugs that will be fixed between versions 11 and 12.

Because, if you paid attention to the scene,

the use of the gratuitous put down is quite a common feature here. Why do you think that is? What was wrong about asking you for a list of bugs as per previous post?

you'll see these releases had nothing special about them (there's no "bugless, stable version for release" to separate it from some "nightly, experimental version", all are experimental), other than some 50 ELO increase minimum that they set, not caring about the bugs (which are discovered and fixed as soon as possible.)

Every day that a bug is reported and fixed in a commit since Stockfish 11, it was a bug that was shipped with Stockfish 11, other than bugs introduced in new code and fixed in a short time frame, the rest have been there for a while.

Then show a list of bugs “that have been there for a while”.

[Pio]

Last one with a full year of usage was Stockfish 10, you have a list of actual real bugs and how they were dealt with?

Here's a list of all changes from Stockfish 10 to Stockfish 11:

a change list is not a bug list

https://github.com/snicolet/Stockfish/c ... 4fb9703583

The fact of life is that Stockfish 10 was shipped with many bugs that were fixed between versions, and Stockfish 11 was shipped with many bugs that will be fixed between versions 11 and 12.

Because, if you paid attention to the scene,

the use of the gratuitous put down is quite a common feature here. Why do you think that is? What was wrong about asking you for a list of bugs as per previous post?

you'll see these releases had nothing special about them (there's no "bugless, stable version for release" to separate it from some "nightly, experimental version", all are experimental), other than some 50 ELO increase minimum that they set, not caring about the bugs (which are discovered and fixed as soon as possible.)

Every day that a bug is reported and fixed in a commit since Stockfish 11, it was a bug that was shipped with Stockfish 11, other than bugs introduced in new code and fixed in a short time frame, the rest have been there for a while.

Then show a list of bugs “that have been there for a while”.

One of the bugs must be that Stockfish does not save the entire board as key in the hash table and thus sometimes will search completely wrong subtrees. If it happens at the root it will be devastating.

Why can’t you try to listen of what H.G.M is saying?

The only difference between H.G.M’s method and That of Stockfish is that I think H.G.M’s is better since it is cheaper. And who knows maybe even the occasional errors will enhance the search. You might think I am joking but the errors might lead to the same positive effect that you can get by randomise the evaluations a little in that the search will favour lines with more options in them. It might also be that H.G.M’s method is better because the erroneous positions might be more erroneous on average thus cheaper to refute. If you are really concerned about errors, you should be concerned about using zobrist hashing in the first place. It is a very small chance that you will have two positions mapping to the same zobrist key, but when it happens there is a very big chance that lots of the children’s and grandchildren’s positions also will have keys that collide. It is a systematic error that can be serious. I guess however that some authors maybe test there zobrist keys to ensure no collision when very few pieces are left.

I guess that you are not a programmer. It is a big difference to think you know everything and actually you know something. I know because I know very little.

[chrisw]

It has not been suggested here yet, but a consideration to look at for hash collision testing is the Hamming Distancehttps://www.chessprogramming.org/Popula ... gDistance .

Some programs like Crafty and Fruit use preset hash keys, but other engines are generating random numbers for every new instance of their engine. If the hamming distance of the zobrist keys are zero, then there is a likelihood of hash key failure, especially with lock-less hashing. This can be tested with:

hamming distance = popcount(a ^ b);

Prompted me to test mine (64*6*2 time seeded random numbers at engine initialisation). left it running, exhaustively testing all five-way xor combinations, except any of self with self, so far after about 700,000,000,000,000 combinations tested, minimum popcount = 5, and maximum = 56. Not sure if that's good, bad or merely indifferent. Or why the popcounts are not balanced.

[chrisw]

It has not been suggested here yet, but a consideration to look at for hash collision testing is the Hamming Distancehttps://www.chessprogramming.org/Popula ... gDistance .

Some programs like Crafty and Fruit use preset hash keys, but other engines are generating random numbers for every new instance of their engine. If the hamming distance of the zobrist keys are zero, then there is a likelihood of hash key failure, especially with lock-less hashing. This can be tested with:

hamming distance = popcount(a ^ b);

Prompted me to test mine (64*6*2 time seeded random numbers at engine initialisation). left it running, exhaustively testing all five-way xor combinations, except any of self with self, so far after about 700,000,000,000,000 combinations tested, minimum popcount = 5, and maximum = 56. Not sure if that's good, bad or merely indifferent. Or why the popcounts are not balanced.

Well, that got to 4 min and 56 max. So now leaving it overnight doing a six-way xor of all with all.

[lucasart]

You don't like it when your stupidity receives extra attention?

Hahahaha! 100% no bugs for chess engines is entirely possible, the mechanics of moving the six pieces in defined ways over 64 squares and performing recursive search are quite trivial. Programmers who won’t work to 100% bug free methods are a liability and unemployable.

Please educate us all, by showing us YOUR 100% bugfree chess engine.

Oh, you don't write code? What a surprise…

[bob]

It has not been suggested here yet, but a consideration to look at for hash collision testing is the Hamming Distancehttps://www.chessprogramming.org/Popula ... gDistance .

Some programs like Crafty and Fruit use preset hash keys, but other engines are generating random numbers for every new instance of their engine. If the hamming distance of the zobrist keys are zero, then there is a likelihood of hash key failure, especially with lock-less hashing. This can be tested with:

hamming distance = popcount(a ^ b);

This was discussed years ago. In the context of trying to take ALL the zobrist numbers (64 bits) and finagle them so that you have the largest possible hamming distance. It turns out to do exactly nothing. And the conclusion at the time was that it might actually hurt somewhat, since many of these numbers get XORed together. Suddenly hamming distance is not quite so important, just so (as you mentioned) the distance is not _too_ low between any two numbers.

[bob]

You don't like it when your stupidity receives extra attention?

Hahahaha! 100% no bugs for chess engines is entirely possible, the mechanics of moving the six pieces in defined ways over 64 squares and performing recursive search are quite trivial. Programmers who won’t work to 100% bug free methods are a liability and unemployable.

Please educate us all, by showing us YOUR 100% bugfree chess engine.

Oh, you don't write code? What a surprise…

I'll say it again, making such a statement is ridiculous since it can not be proven. HGM is correct that his 100 line program could well go through an automatic verification tool to confirm correctness. IF there is a 100% correct software specification. So a double-whammy. Is the spec correct? Is the program correct? are both then correct?

But for normal chess programs, NOBODY can claim that a program is 100% bug free because such a statement requires proof. Proof that is impossible to produce. Why this keeps going around in circles, I don't understand. If you make the claim, you have to show the proof. Running with zero visible problems for a year is _NOT_ a proof.

This statement: "the mechanics of moving the six pieces in defined ways over 64 squares and performing recursive search are quite trivia" shows the lack of thought applied here. What about the mechanics of a chess evaluation? The mechanics of the actual search. The mechanics of the actual move generation. The mechanics of move ordering. The mechanics of hashing. The mechanics of parallel search. The mechanics of ... This list goes on and on and each example significantly adds to the total complexity of the chess engine.

I'm not interested in commercial data processing programs. They can be extreme in size, but simple in overall design. Just lots of code. A chess engine is the exact opposite. Not nearly as large, but MUCH more complex in the internal pieces of the program. And note I am talking about an actually functional, strong chess engine. Not the mentioned "recursive search is trivial" point above, which represents less than 1% of the program's complexity. In fact, some don't use recursion anyway, so that's a moot point.