Page 2 of 2
Re: transposition table pseudocode
Posted: Wed Aug 24, 2016 12:21 pm
by zenpawn
Thank you all for your validations and suggestions. It helped me to stop focusing on these parts and find the silly bug in code not shown here.
Hopefully the initial pseudocode, with the followup correction and your tweaks, will serve as a good starting place for the next intrepid chess programmer adding a transposition table to their engine.
Re: transposition table pseudocode
Posted: Wed Aug 24, 2016 12:54 pm
by Sven
zenpawn wrote:Thank you all for your validations and suggestions. It helped me to stop focusing on these parts and find the silly bug in code not shown here.
Hopefully the initial pseudocode, with the followup correction and your tweaks, will serve as a good starting place for the next intrepid chess programmer adding a transposition table to their engine.
Nice to read that. So was the bug related to transposition table handling or not? You seemed to have excluded that it wasn't.
Re: transposition table pseudocode
Posted: Wed Aug 24, 2016 1:20 pm
by zenpawn
Sven Schüle wrote:
Nice to read that. So was the bug related to transposition table handling or not? You seemed to have excluded that it wasn't.
Yes, related. It's a bit embarrassing, but here goes... At some point, I decided it was clever to use the fact a move was the only one available to save its eval before the alpha-beta checks in the pseudocode above as, get this, an Exact type. It didn't hurt too badly until I added TT to the qsearch, which has many more "only" moves. However, it was wrong it both cases.
Re: transposition table pseudocode
Posted: Wed Aug 24, 2016 1:41 pm
by Henk
PK wrote:popular source of transposition table bugs is saving score after a search has run out of time.
Code: Select all
public void Store( ... )
{
if (Position.Expired) return;
..
}
Re: transposition table pseudocode
Posted: Wed Aug 24, 2016 2:07 pm
by Henk
I'd better call it Search.Expired