Author: Roberto Waldteufel
Date: 14:49:21 10/09/98
Go up one level in this thread
On October 09, 1998 at 15:44:25, John Coffey wrote: >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 John, be very careful - it is dangerous to assume anything you can't test or prove. Have you seen the Savedra position? It is a famous endgame study: WKg6, WPf6, BKh1, BRe5, White to play. This could arise out of KPPKP. The solution is 1.f7 Re6+ 2.Kg5 Re5+ 3Kg4 Rg4+ 4. Kg3 Re3+ 5 Kf2 Re4! 6. f8=R!! (6.Kf3 Re1, 6.f8=Q? Rf4+ Qxf4 stalemate) 6.....Rh4 7.Kg3 winning the rook. This kind of thing is very pretty when you see it as a study, but it is a nightmare if you are trying to determine the game-theoretic values of chess positions with large disparities of material. If you are evaluating huge numbers of such positions, you will have to do it automatically, and you never know for sure if there were some mistakes, which would then propogate fale results to lots of other parent positions. I wish you luck - I think what you are taking on is very difficult indeed. Best wishes, Roberto
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.