Author: Matthew White
Date: 11:03:29 05/30/03
Go up one level in this thread
On May 29, 2003 at 22:54:01, Russell Reagan wrote: >On May 29, 2003 at 20:23:03, Matthew White wrote: > >>K+P vs. K is already in tablebases. I am not really interested in finding a >>replacement for tablebases, rather finding a way to improve endgame performance. >>At this point, I am merely brainstorming. > >I know, I was only saying that there is more to it than loading a single >position into the transposition table. Don't get me wrong either. I like your >idea. I'm just playing devil's advocate a little. > >>You mention that it is unrealistic to store all of the positions necessary for >>key positions. However, many of us have hundreds of megabytes (maybe even a few >>gigabytes) worth of opening book sitting on our hard drives. Wouldn't it be an >>effective use of space to build an endgame tree just like the opening tree? > >But my point (and something you already mentioned in your original post) is that >you will have to store a LOT of positions (WAY more than gigabytes, WAY more >than terabytes even) to make sure we get every "Phildor position" stored (or >whatever the endgame position in question is). Maybe a pawn is one square >different from the position you have stored. That doesn't really matter because >the key points are the placements of the rooks (or whatever, just an example). >This is one area that partition search might be of use, because you can have >kind of "wild cards". Something like this: > >white to move > >8 k - - - - - - - >7 - - - - - - - - >6 - K - - - - - - >5 - - - - - - - - >4 - - - - - - - - >3 - - - - - - - - >2 - - - - - - R - >1 ? - ? ? ? ? - ? > > a b c d e f g h > >The question marks (?) represent squares where it doesn't matter what piece is >there (there are more in this position, but it's just an example). I believe >this is the kind of stuff you can do with partition search. You store this kind >of "wild card position" in the transposition table instead of "real" positions, >and so if there is a black rook on a1, or if a1 is emtpy, you will still find >this position in the transposition table, and get its score. > >>In >>certain openings, one player is playing for an endgame advantage. If a computer >>doesn't realize that they are playing for an endgame advantage, they will avoid >>trades and try to find a middlegame win. This can lead to big problems. However, >>if the hash table contains a position from the endgame which is a known win, and >>a quiescence search hits that position, the computer will know it is safe to >>seek an endgame. I believe that the endgame book would also prove smaller than >>an opening book in most cases, since there are often forced moves. This is a >>luxury that opening books don't usually have. > >Makes sense, but not for a "normal" transposition table, because you'd have to >store a LOT of these endgame positions, probably a lot more than you could store >in memory or on your hard drive. Partition search still sounds good. > >>I agree that many endgames are a pattern, and cannot be captured in book form. >>However, there are probably as many endgames that just need brute calculation. >>Certain openings inevitably lead to certain endings. I am not proposing a total >>endgame substitute, where the book will just take over whenever and endgame is >>reached... it is more like a crutch. > >Not a bad idea. Put little "hints" in some kind of table, so that the program >will play certain correct moves in positions it doesn't really understand. If >this method could be generalized and made to be efficient, I think you'd have a >computer program with a GM level understanding of chess, that could look at >millions of positions per second. Scary. Thanks for playing devil's advocate :). I think that wildcards might definitely reduce the size in cases where the actual position of some of the pieces doesn't matter, and I think hints are definitely a possibility. Now I just have to figure out a way to get it implemented :). Matt
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.