Hi,
could someone (Bob) please pinpoint the fix to the bug described below in main.c ?
thanks in advance,
Alvaro
Bug in hash implementation fixed. It was possible to get a hash hit at ply=2, and alter the ply=1 PV when it should be left with no hange. This could cause Crafty to display one move as best and play another move entirely. Usually this move was OK, but it could, on occasion, be an outright blunder. This has been fixed.
crafty question
Moderators: hgm, Rebel, chrisw
-
- Posts: 362
- Joined: Thu Mar 16, 2006 7:39 pm
- Location: Portugal
- Full name: Alvaro Cardoso
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: crafty question
I had to do the "SavePV() call in "case EXACT:" in HashProbe(), but it had to be protected by if (val > alpha && val < beta). This was something that was only a problem at ply=2, where I could get an EXACT hit, but the score was not good enough, yet it would stuff the ply 1 move into the PV anyway. You could probably diff hash.c from the version before with the version with the fix and see the exact change...Cardoso wrote:Hi,
could someone (Bob) please pinpoint the fix to the bug described below in main.c ?
thanks in advance,
Alvaro
Bug in hash implementation fixed. It was possible to get a hash hit at ply=2, and alter the ply=1 PV when it should be left with no change. This could cause Crafty to display one move as best and play another move entirely. Usually this move was OK, but it could, on occasion, be an outright blunder. This has been fixed.