Author: Les Fernandez
Date: 17:00:08 04/16/99
Go up one level in this thread
On April 16, 1999 at 11:37:38, KarinsDad wrote: >I think it would be easy to have special code for endgames. There would just >have to be ALOT of special cases, so the creation of the more complex algorithms >may be difficult (depending on whether you could build complex ending >calculations based on simple ending code). > >One could have a 32 bit value for all of the pieces and the evaluation routine >could check to see if at any point in the search whether that value is in the >subset of special endgame ones. If so, it could use a series of special endgame >code for those endgame pieces. For example: > >p = 1 >n = 16 >b = 128 >r = 1024 >q = 8192 > >Since the kings are not needed (they are always on the board), this structure >allows up to 8 pawns, 7 knights, 7 bishops, 7 rooks, and 7 queens for each side >in a 32 bit structure (however, the down side is that you have to count up the >number of each type of piece for each side, but if you are calculating the >"tree" on the stack, then this would at least be a delta calculation). > >In the case of KR vs. K, this value would have to be checked against 1024 for >one color and 6815744 (1024 * 64K or 1024 shifted 16 bits to the left) for the >other color. Those would be the only two legitimate KR vs. K values. > >The special endgame code could be placed into multiple DLLs that only get >uploaded into memory if the search engine comes across one of the special cases. >This would be similar to the current tablebases, however, if it was done >properly, the more complex endings would be set up to use code from multiple >less complex endings in order to calculate the proper set of moves. In other >words, unlike the tablebases which are exhaustively searched for the best moves, >this system would use a building block type of approach to calculate the best >move. > >Additionally, each simple endgame DLL could have a list of all possible >positions with the corresponding list of results (i.e. 1-0, 1/2-1/2, or 0-1) for >each of them. This would enable the search engine (similar to how tablebases are >used today) to instantly determine if the position is a win, a draw, or a loss. >It would only use the algorithm to figure out HOW to play. > >Does this approach seem reasonable (I realize that the building block approach >part of it is complex and would take a lot of work)? > >KarinsDad :) Hello and welcome Karinsdad, This subject caught my attention since just about 2 weeks ago I spoke with Dann Corbit, founder of the C.A.P. project about this very question. I always wondered given a certain endgame position, ie any position which was based on say KR vs kn as Bruce's example, if we understood the theory in this 4 piece ending. Since we know according to tablebases that positions exist that lead to wins, draws and loses, it implies that atleast in the win case scenario that some logical understanding about that particular set of pieces has to exist. The big question is how do we find it. Perhaps their may be several viable approaches. Maybe a piece of software designed to look for pattern recognition, etc. Anyway I tend to agree that if these collections can be handled via an algorithm vs tablebase that would be a tremendous contribution to the field. And lets say that several collections solutions can be found, then we could remove that part of the egtb thereby shrinking it down as progress is made. Anyway I am glad you brought up the subject for I believe this area of research could be very interesting. Les
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.