Possible "real" hash collision

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
xr_a_y
Posts: 542
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Possible "real" hash collision

Post by xr_a_y » Wed May 22, 2019 7:49 pm

JVMerlino wrote:
Wed May 22, 2019 7:46 pm
I recall that one thing I tried when I was having a similar problem (or, at least, I suspected there was something wrong with repetition detection), was not saving positions to the TT that were given a draw score due to repetition. I think it pointed me in the right direction, but it was so long ago that I can't remember what the problem was. :oops:
I think I tried in Weini to not use draw score from TT for the same purpose ... I'll try that tomorrow, thanks

Joost Buijs
Posts: 845
Joined: Thu Jul 16, 2009 8:47 am
Location: Almere, The Netherlands

Re: Possible "real" hash collision

Post by Joost Buijs » Thu May 23, 2019 5:07 am

It could be a lack of king safety. Black is 2 pawns behind, if the engine doesn't understand the threats towards the white king it could just be happy with a draw by repetition from blacks point of view. This is only a suggestion, if you really want to know what is going on you have to analyze the position step by step, and take a look at the static evaluation for all the relevant variations.

jdart
Posts: 3730
Joined: Fri Mar 10, 2006 4:23 am
Location: http://www.arasanchess.org

Re: Possible "real" hash collision

Post by jdart » Thu May 23, 2019 11:43 am

It is well known that you must not rely on the hash table for anything that is dangerous if inaccurate. For example I used to retrieve check status (is side to move in check?). But in case of a collision, getting this wrong could cause a crash. That said, there are many other possible causes of crash bugs. Running under Valgrind or similar tools is a good way to find issues.

User avatar
xr_a_y
Posts: 542
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Possible "real" hash collision

Post by xr_a_y » Thu May 23, 2019 12:21 pm

jdart wrote:
Thu May 23, 2019 11:43 am
It is well known that you must not rely on the hash table for anything that is dangerous if inaccurate. For example I used to retrieve check status (is side to move in check?). But in case of a collision, getting this wrong could cause a crash. That said, there are many other possible causes of crash bugs. Running under Valgrind or similar tools is a good way to find issues.
Indeed Jon, but we are not looking for a crash thing here, only a blunder.
In fact a somehow deep blunder because of delaying checks ; not directly liked to TT usage, nor pruning. Probably something just about draw management.

I like the idea given before that a better king attack score (or rook on 7th rank) would have help Minic to not fall in the bad move.

brianr
Posts: 338
Joined: Thu Mar 09, 2006 2:01 pm

Re: Possible "real" hash collision

Post by brianr » Thu May 23, 2019 1:26 pm

It might not be an issue in this case, but something that many engines (including Tinker) are surprisingly sensitive to is how to handle repetitions. I have found that the full 3-reps test should be used at the root, but anywhere in the search to score the 2nd rep as a draw and not to wait for the 3rd. I also have tried to count consecutive checks in a fruitless effort to detect perpetuals, but it never seemed to help and occasionally hurt, so it is not used.

User avatar
xr_a_y
Posts: 542
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Possible "real" hash collision

Post by xr_a_y » Thu May 23, 2019 1:28 pm

brianr wrote:
Thu May 23, 2019 1:26 pm
It might not be an issue in this case, but something that many engines (including Tinker) are surprisingly sensitive to is how to handle repetitions. I have found that the full 3-reps test should be used at the root, but anywhere in the search to score the 2nd rep as a draw and not to wait for the 3rd. I also have tried to count consecutive checks in a fruitless effort to detect perpetuals, but it never seemed to help and occasionally hurt, so it is not used.
I test for 3 reps at pvnode (and root) and 1 rep everywhere else. I think it was a HGM advice to test only 1 rep when I was struggling with Weini.

brianr
Posts: 338
Joined: Thu Mar 09, 2006 2:01 pm

Re: Possible "real" hash collision

Post by brianr » Thu May 23, 2019 2:20 pm

Maybe just try not testing for 3 on PV nodes, only at the root.

User avatar
xr_a_y
Posts: 542
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Possible "real" hash collision

Post by xr_a_y » Thu May 23, 2019 5:45 pm

Ok, using TT in qsearch solve the issue ... and gives +50elo ... don't really know why ... side effect maybe

Post Reply