Author: Russell Reagan
Date: 19:54:01 05/29/03
Go up one level in this thread
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.
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.