Do exact node cut offs from TT produce wrong results?
I have tried writing PVS search both ways and get correct results only when an exact score returned by a TT lookup is not used to give a cut off, but only gives best move. Occasionally the cut off method produces the wrong result.
Does this mean I have a bug in the code?
An example: Fine position 70
with cut off: best move (ply 26) Ka1-b2 ( incorrect - white loses King opposition )
without cut off: best move (ply 26) Ka1-b1 ( correct - white wins a pawn )
Do exact node cut offs from TT produce wrong results?
Moderator: Ras
-
kdjones
- Posts: 9
- Joined: Mon Feb 08, 2016 7:06 pm
- Location: Nova Scotia, Canada
-
syzygy
- Posts: 5874
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Do exact node cut offs from TT produce wrong results?
If you get a winning score for Ka1-b2, you have a bug.
Taking exact node cut offs is certainly not a bug in itself. Why would it...
Taking exact node cut offs is certainly not a bug in itself. Why would it...
-
Steve Maughan
- Posts: 1315
- Joined: Wed Mar 08, 2006 8:28 pm
- Location: Florida, USA
Re: Do exact node cut offs from TT produce wrong results?
You'll only get an error if you have path dependant evaluation terms,
Steve
Steve
http://www.chessprogramming.net - Juggernaut & Maverick Chess Engine
-
AndrewGrant
- Posts: 1969
- Joined: Tue Apr 19, 2016 6:08 am
- Location: U.S.A
- Full name: Andrew Grant
Re: Do exact node cut offs from TT produce wrong results?
Are you missing a condition like the following
Code: Select all
if (entry->depth >= depth && entry->type == EXACT) doTheCutOff-
kdjones
- Posts: 9
- Joined: Mon Feb 08, 2016 7:06 pm
- Location: Nova Scotia, Canada
Re: Do exact node cut offs from TT produce wrong results?
Thanks. I believe I have equivalent code. Here is my hash table retrieval code:
Code: Select all
bool ProbeHashTable( U32 *move, int *score, int alpha, int beta, int depth)
{
U32 index = static_cast < U32 > ( hashKey ) % hashEntries;
hashTable.probes ++;
if ( hashTable.entry[ index ].signature == static_cast < U32 > ( hashKey >> 32 ) ) {
*move = hashTable.entry[ index ].move; // for move ordering
if ( hashTable.entry[ index ].depth >= depth ) {
hashTable.hits ++;
*score = hashTable.entry[ index ].score;
if ( abs( *score ) > mateScore ) {
if ( *score < 0 )
*score = depth - Infinity;
else
*score = Infinity - depth;
}
switch ( hashTable.entry[ index ].flags ) {
case HFnone:
return false;
case HFalpha:
if ( *score <= alpha ) {
*score = alpha;
return true;
}
return false;
case HFbeta:
if ( *score >= beta ) {
*score = beta;
return true;
}
return false;
case HFexact:
return true; // take cutoff
}
}
}
return false;
}-
kdjones
- Posts: 9
- Joined: Mon Feb 08, 2016 7:06 pm
- Location: Nova Scotia, Canada
Re: Do exact node cut offs from TT produce wrong results?
Thanks. I don't believe I do.
-
kdjones
- Posts: 9
- Joined: Mon Feb 08, 2016 7:06 pm
- Location: Nova Scotia, Canada
Re: Do exact node cut offs from TT produce wrong results?
Yes, I get a winning score at 26 ply.
cutoff: 26. Ka1-b2 score 186 ( previous ply score 85 )
no cut: 26. Ka1-b1 score 185 ( previous ply score 85 )
The problem seems to be in the collection of the PV from the TT. The PV then is used to order the moves.
cutoff: 26. Ka1-b2 score 186 ( previous ply score 85 )
no cut: 26. Ka1-b1 score 185 ( previous ply score 85 )
The problem seems to be in the collection of the PV from the TT. The PV then is used to order the moves.