Author: Simon Finn
Date: 05:45:09 07/11/02
Go up one level in this thread
On July 10, 2002 at 16:23:54, Daniel Clausen wrote: >On July 10, 2002 at 14:17:04, GuyHaworth wrote: > >> >>Yes, if you are computing your EGT(B) to the DTM(ate) metric. >> >>You might find a 'mate in many moves', only to discover that there was a much >>quicker 'mate in much few moves' which appears many retrograde_cycles later in >>the computation. >> >>For example, I forget the exact position but you will get the idea: >> >>wQb3wBh1h2/bKa1bNe1+w .... >> >>1.Qa2+ forcing Kxb2 leaves (I guess) a deep KBBKN win >> >>This mate would be found two cycles into the retrograde_analysis of KQBBKN but >>a much quicker win using the Queen would turn up later. > >Well yes, but I still don't see a problem. If you only mark the positions which >are 'mate in 2' during the 2nd cycle and leave the other positions untouched, >you don't have this problem. The best you could do for this position in the 2nd >cycle is to mark it as a 'potentially mate in 1+(DTM-value of KBBKN)' [a mate in >X in iteration Y is only a potential mate if X>Y] > >I don't see a reason why I would want to do this, especially if this 'error' >even propagates to other positions during later iterations. So why not simply >leave the position unmarked in this case? Would generating the table be that >more slow? The approach you describe requires max-DTM iterations. For some endgames - such as KBNKR (where all wins are based on a quick mate or quick conversion) - this is substantially more than with the alternative technique. You also need to keep the conversion databases available throughout the algorithm, rather than being able to discard them after a pre-pass. This can increase memory usage and/or disk I/O. Simon > >Sargon
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.