Author: blass uri
Date: 22:15:10 10/09/98
Go up one level in this thread
On October 09, 1998 at 17:49:21, Roberto Waldteufel wrote: > >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. how can it arise practicaly out of KPPKP This could arise only if black promote the pawn to a rook but I see no logical reason to do it when the white pawns are not near the queen square Uri 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. RvPP is not a large disparities of material and I do not need to eveluate RvPP when QvPP is winning >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 you can do rules that there will never be a mistake and you can give the unknown results for part of the endings if you have problem to generate the tablebases because of the huge number of positions. Uri
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.