Author: Robert Hyatt
Date: 05:46:19 01/26/99
Go up one level in this thread
On January 25, 1999 at 22:48:02, Nuno Maltez wrote: >Hi, > >I've stumbled on what looks like a silly problem (bug) using Fritz 5.32 and >endgame databases. I don't know if this has been mentioned before, but I've >don't remeber reading anything about it neither here nor in rgcc (I don't read >every post though), so here it goes: > >Take the following position (Black to move): >White: Kg6, Rh4, Ph3 >Black: Kg8, Rf7 > >I was playing black (we got here from an endgame position taken from a textbook) >and moved 1...Rg7+. Fritz using the databases evaluated all continuations as (0) >and played 2.Kh6. I replyed 2...Rh7+ and here Fritz evaluated again all moves as >(0) and played the unbelievable 3.Kg6?? losing the rook and the game. After >3...Rxh4 it returned to the normal engine and quickly realized white is lost. > >Has anyone faced this problem before? I'm using a Fritz 5.32 update downloaded >from Chessbase's site late December. I've not tested other positions, but it >looks like the program's not noticing the difference between a draw and a loss >(database problem?). Is this some configuration problem or what? > >Thanks in advance, >Nuno I didn't look at the specific position, but this problem has been long known in fritz, because it uses Ken Thompson's 'distance to conversion' databases. IE it tries to choose the move leading to the shortest 'conversion' to a fewer number of pieces that is drawn, but it doesn't pay attention to the actual board position. In the case I saw and reported here last year, it walked into a simple mate in 2 by trying to trade pieces... the distance to mate databases don't have this problem. I haven't given any thought to how to fix it in a DTC program since I have no plans to do such a database probe...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.