Author: Ricardo Gibert
Date: 15:49:58 09/10/99
Go up one level in this thread
On September 10, 1999 at 11:03:38, Robert Hyatt wrote: >On September 10, 1999 at 09:56:30, Ricardo Gibert wrote: > >>On September 10, 1999 at 00:20:59, Robert Hyatt wrote: >> >>>On September 09, 1999 at 21:57:28, Ricardo Gibert wrote: >>> >>>>Would it be feasible to generate an EGTB in the following manner: Instead of >>>>storing DTM or DTC in the EGTB, how about storing "nth generated move progresses >>>>towards mate"? It would seem this would be more compact in some endings. An old >>>>idea? Yes? No? Maybe? Incorporating a little primitive AI to order the moves >>>>generated would make the the tables even more compact. >>> >>> >>>Suppose _all_ moves head toward mate. How do you pick the one that leads to >>>the shortest mate? Not important? If you keep choosing a move that leads to >>>a mate in 10, you eventually run into the 50-move rule. This is why everyone >>>likes distance-to-mate databases. >> >>You missed the key word "progresses". You are including what I call >>retro-gressive moves leading to mate i.e. prolongs the win. >> >>I do need to amend my description for a very different reason, however. There is >>a problem in extracting reasonable defensive tries. How does the defender best >>prolong the game to delay its loss? "Nth generated move that is optimal rather >>than "Nth generated move progresses to mate" would include defenders best best >>defensive tries. All you need to know is that a move is optimal and not whether >>it mates in X number of moves or that it wins or draws. But this amendment is >>moot as the idea has other problems. DTM can be partitioned into smaller pieces, >>which makes it better memory wise. > >If you only store a single index, how is this more efficient than Eugene's >format? IE you are going to have to use 8 bits for the move index, he is using >8 bits for the distance to mate score, so it seems to be a 'wash'. IE your >approach seems to be no different from what we already get with Eugene's, >because we _can_ get the move that 'progresses' trivially. From the current >database 'hit' position, generate all moves, probe for each one, and take the >one that leads to the quickest mate... Nth generated move should be a smaller number, even smaller still if the moves are re-ordered with a little "AI". Example, the moves can be re-ordered by placing moves that do not hang a piece or decentralize the King ahead of those that do. This will improve the compressability of the EGTB. This is what I'm after. > >The main problem with the index into a move list is that it requires that >everyone use the same canonical move generator order, something that is very >non-trivial. We want the probe code to fit into a chess engine very easily, >not require special move generator order or whatever to make it work... They can use any move generator they want. Sorting is trivial.
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.