Author: Dave Gomboc
Date: 20:21:16 08/03/99
Go up one level in this thread
On August 03, 1999 at 22:37:53, Ricardo Gibert wrote: >On August 03, 1999 at 19:27:18, Ricardo Gibert wrote: > >>On August 03, 1999 at 19:09:29, KarinsDad wrote: >> >>>On August 03, 1999 at 18:45:49, Ricardo Gibert wrote: >>> >>>[snip] >>>> >>>>Yes, this is workable, but how could it be better? There can be a lot of leaf >>>>nodes that could hit the EGTB and the extra time spent taking care of the 50 >>>>move rule could be better spent some where else. Some of the EGTB hits will >>>>return mate in over 50. The program has to go further down the line to make sure >>>>a pawn move or capture takes place before 50 moves are played. For example: mate >>>>in 110 will require the program to find more than one pawn move or capture. Why >>>>bother when you don't have to? >>> >>>If you are in a mate in 110 situation (probably extremely rare), it would >>>probably behoove you to do your own searching for capture/push moves that lead >>>to positions that maintain the win since you will probably find them relatively >>>close to the main line anyway. Compared to searching even something as simple as >>>an 8 ply alpha-beta, searching for those moves would take VERY little time. The >>>reason this works out so well is that you do not have to search outside the >>>tablebase once you are in it (or once you are close enough to it to force your >>>way into it). >> >>In many pawnless EGs a "good" capture can be hard to come by. 8 ply would not do >>it in that case. >> >>> >>>From what I have been told, 5 piece tablebases take about a month to generate on >>>a 500 Mhz system (more or less). In order to regenerate the work done so far on >>>6 piece tablebases would be a great deal of work. >>> >>>Yes, you could improve upon the tablebases by doing what you suggest, however, I >>>would expect that it would significantly increase the time required to generate >>>the table, possibly by a factor of x2 or more. I realize that this would not be >>>a great amount of time for 3, 4, and 5 piece tablebases, but for those people >>>currently generating 6 piece tablebases, it's probably a significant amount of >>>time (even if they were to find a way to keep the data they already have and >>>just add to it). >> >>I'm not sure if it would take longer, but if so, I can understand the trade off >>of allowing draws in winning positions, since they are extremely rare. This is a >>good point you make. >> >>> >>>So, all in all, it seems that you could improve upon them, but there probably >>>isn't a need when it can be handled in real time within the program for those >>>few instances when it would be needed. JMO. >>> >>>KarinsDad :) > >PS: Thinking about it some more, I'm leading more strongly to your explanation. >However, I think the problem may be one of space OR time (as you suggested). You >could trade one for the other. Congratulations on being the 1st to produce >justification for distance to mate being preferred. Now I believe Nalimov EGTBs >can be distance to mate. Otherwise, it would be silly. AFAIK Eugene's stuff is DTM. I think that most of us don't really care beans about the 50-move rule, e.g. it is there because humans don't want to be dragged through three adjournments in a slightly worse ending just in case they blunder. Of course, there's more to it than that, but get out a piece of paper, and write down some reasons why the 50-move rule exists. Now, go through this list, and cross off all of the ones that are still relevant when both participants have perfect information and play their moves virtually instantly. I'll be surprised if you're left with more than zero reasons. It's my opinion that, in games between computers, the 50-move rule should only be in effect when a contestant cannot demonstrate a forced victory for itself. Dave
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.