Author: J. Wesley Cleveland
Date: 18:37:29 01/31/04
Go up one level in this thread
On January 30, 2004 at 14:37:45, Robert Hyatt wrote: >On January 30, 2004 at 13:24:25, J. Wesley Cleveland wrote: > >>On January 30, 2004 at 09:45:23, Robert Hyatt wrote: >> >>>On January 30, 2004 at 02:48:52, GuyHaworth wrote: >>> >>>> >>>>Speed only becomes an issue when a specific endgame becomes 'relevant'. >>>> >>>>Longer term, it would be good to have more dynamic storage schemes which only >>>>promote EGTs to hard disc 'Just In Time' before they're needed. >>>> >>>>In round figures, I estimate 1.5TBytes for the 3-to-6-man DTM EGTs, but only >>>>0.6TBytes for the DTZ and EdZ50Z EGTs (from which the DTZ50 EGTs can be >>>>derived). >>>> >>>>In either case, I anticipate some robotic DVD-handler would be useful. >>>> >>>>g >>> >>> >>>The problem is, what happens on (say) a KRPP vs KR. Potentially you will need >>>KR** vs KR for all the promotions. When you reach that position, your search >>>will simply end, because there's no way you will copy all the KR**KR files from >>>DVD to the hard disk while a search is in progress. >> >>You won't need KR** vs KR until the root position is KRPP vs KR. Since your >>"searches" will then be only 1 ply, there may well be time. > > >What do you do with KRPP vs KR positions deep in the tree where you need to >promote? I take the exact value from the KRPP vs KR table and prune. You only need the KR** vs KR tables if you promote with a capture. And you can't since you don't have the table? That's the place where >tables help, in the search. _not_ at the root. By the time you reach the >position OTB it is already won lost or drawn. In the search, you can control >where you reach the table position and choose winning over drawing...
This page took 0.01 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.