Author: Robert Hyatt
Date: 08:03:38 09/10/99
Go up one level in this thread
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... 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...
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.