Author: Robert Hyatt
Date: 12:47:47 05/14/01
Go up one level in this thread
On May 14, 2001 at 14:51:16, J. Wesley Cleveland wrote: >On May 13, 2001 at 22:42:00, Robert Hyatt wrote: > >>On May 13, 2001 at 19:48:59, J. Wesley Cleveland wrote: >> >>>On May 12, 2001 at 20:41:23, Robert Hyatt wrote: >>> >>>>On May 11, 2001 at 16:50:28, J. Wesley Cleveland wrote: >>>> >>>>>Okay. With exact results, you only need the number of plies to the next capture >>>>>or pawn move stored with each position to solve the 50 move rule problem. >>>>>Repititions are a non-problem, i.e. if from position A, you know that position B >>>>>is a forced win, *but* the win leads back through A, you would never choose to >>>>>move to B, because you would already know there is a shorter win from A. >>>> >>>> >>>>How would you _know_ that either of those positions were forced wins if you >>>>don't save _everything_ as you search? >>>> >>>You know because you have a string of positions in the hash table, each of which >>>is one ply closer to mate. There *can't* be a repitition, or it would be a >>>different string. It is just like endgame tablebases, which do not need any >>>history of positions. >> >> >>I'm not sure I follow. Endgame tables have _all_ positions available during >>their creation. That is how the algorithm works.. find a position that is >>marked as "unknown" by backtracking from a position marked as "known". Then >>you can mark the unknown entry as mate in one more move than the known entry. >>But you must have _all_ positions stored during the creation... _every_ one. > >I thought that is what we were discussing. If you have a hash table large enough >to store every position found in the search, then you do not need total path >information with each position, which means you could solve chess by considering >"only" about 10^25 positions. So, if Moore's law holds up, we could solve chess >by the end of the century, rather than by the end of the universe. First, how do you conclude 10^25? assuming alpha/beta and sqrt(N)? Note that the tablebases would not contain just 10^25 positions. They would contain the usual number which is roughly 64^32 for every position. And also note that even though they can be _stored_ in that much memory, the time required to build them is absolutely enormous. IE how many iterations for the longest possible forced mate? NO idea here, but if we are talking about 10,000 plies, you can forget constructing them even if you_can_ store them. And I don't see storing 64^32 anytime soon. That is an enormous number. And that pales in terms of the number of operations required to build the thing. IE why do you think some of the simple 6 piece files are taking months? When the file sizes are < 10 gigabytes?
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.