Author: Robert Hyatt
Date: 21:47:46 09/10/99
Go up one level in this thread
On September 10, 1999 at 18:49:58, Ricardo Gibert wrote: >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. > I'm not sure how this will work... what do you store for all the draw positions? 0? So you get into the same 'range' for compression as with Eugene's approach. But for a canonical generator index, you _must_ use 8 bits, because we already have seen _many_ positions with > 127 legal moves, which requires either 8 bits to store, or even worse, starting to offset table entries by fractions of a byte... >> >>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. Remember that we (some of us at least) are probing _deep_ in the search. Sorting is not trivial there when it can be done hundreds of thousands of times for a single move.
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.