Author: John Coffey
Date: 12:44:25 10/09/98
Go up one level in this thread
On October 09, 1998 at 14:56:46, José de Jesús García Ruvalcaba wrote: > >To make a tablebase, you need all of its descendants first. The direct sons of >KPPKP are: >KPKP (black captures one white pawn) >KPPK (white captures the black pawn) >KQPKP (white promotes to a queen) >KRPKP (white promotes to a rook) >KBPKP (white promotes to a bishop) >KNPKP (white promotes to a knight) >KPPKQ (black promotes to a queen) >KPPKR (black promotes to a rook) >KPPKB (black promotes to a bishop) >KPPKN (black promotes to a knight) > And each one of these has its own sons, which must be calculated first, until >you reach KK, KBK or KNK (which are drawn). So, your storage requirements might >be a little higher. > With so many pawns, a tablebase with little information (like the one you want >to make), could be useful, as you can search only the branches which do not >decrease the exact score for the side to move. Realistically if I am going to make a KPP vs KP database (and subsets with smaller numbers of pawns), then I only need to know if a position is a win, draw, or loss or unknown. If I start with positions where pawns are close to queening then I should be able to determine that from calculation. Other positions will be able to force into the positions that I already calculated, so I can build the database from there. In this case I would have to consider a win as having a material advantage of at least a rook. Sure I would like to have all the other databases, but I am trying to get something practical here that doesn't take up too much space. It would be nice to know the number of moves until mate, but with KPP vs KP I don't feel it is necessary. Instead the database will allow two things: 1. Cutoffs in the middle of the tree when reaching a position in the database. This is assuming that we don't start from a known position. 2. If I already start with a known position then I can get a list of candidate moves that still win or draw. I wont examine other moves and I won't be looking at the tablebase in the search. Instead I will try to determine which of the candidate moves wins the most quickly. I could get more information with more space, but we are talking a gig database here. John Coffey
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.