Author: Steve Schooler
Date: 04:42:21 02/27/01
In Fritz 6 versus Steve Ham at
http://correspondencechess.com/campbell/ham/fr_hambl.htm
the position after 56. Rc6+ was
[D]8/2k5/1pR5/1K6/P2b4/8/8/8 b - - 0 56
Steve Ham's annotation indicates how difficult this position is for standard
computer search algorithms. I was intrigued because 6 man tablebases are not
yet readily available. However, I believe that this position can be routinely
resolved by using the following algorithm to dynamically generate a PARTIAL
tablebase:
1. Clearly, the position is either a win for White, or a draw. Further, it
seems safe to assume that if White has a forced win, then White also has a
forced win that does not allow the Black pawn to promote.
2. Construct an ordered list of all possible positions (including promotions)
that can legally arise from the base position (after White's 56. Rc6+). This
list will include positions with 2, 3, 4, 5, and 6 pieces.
3. From this list, exclude all positions that require a Black promotion (re # 1
above). Denote the ordered list of remaining positions as the _ordered
universe_.
4. Use a Nalimov-type algorithm to assign a 1 byte evaluation to each position
in the ordered universe (i.e. draw, distance to forced mate for white, or
distance to forced mate for black). For example, suppose a specific position
evaluates to mate in 17 for White. This (must) imply that White can force a
mate in 17, where each intermediate position in the forced sequence of moves is
in the ordered universe.
5. As the user considers any intermediate position in the ordered universe,
interface software must generate a list of all possible positions in the ordered
universe that are 1/2 ply from the intermediate position. For each of these
possible positions, the interface software must then probe the partial tablebase
generated in #4 above and retrieve the associated evaluation.
Unfortunately, this approach probably has many difficulties. The difficulties
that I've noticed are:
1. Need standard method of starting with base position (e.g. after 56. Rc6+)
and constraint (e.g. no Black promotion) and generating ordered universe.
2. I believe it's impractical to try to store the ordered universe on hard
disk. This makes step 5 (above) problematic. Recommended method for step 5:
given any (random) position in the ordered universe, dynamically calculate where
this position is represented in the partial tablebase.
3. I'm ignorant of the internal methods used in generating a standard Nalimov
tablebase (including compression methods). Consequently, I can't even speculate
on the difficulties associated with step 4 (above).
------------------------------------
Although the above problems are probably surmountable, will there be sufficient
public interest to make the approach worth the effort? Plausibly, the approach
will only be relevant for starting-positions/constraints that are "1 PIECE"
beyond current hardware/software resources for tablebase generation.
Recent posts for the position diagrammed below have suggested both Ra4 and Rd5
as winning moves. Even if the above approach is implemented, it could be over a
decade before a user can routinely resolve a position with this many pieces by
partial-tablebase probing.
[D]8/5p1k/r5pp/P7/3R3P/6P1/5PK1/8 w - - 0 1
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.