Author: Uri Blass
Date: 12:48:14 01/13/05
Go up one level in this thread
On January 13, 2005 at 13:45:04, Dann Corbit wrote: >On January 12, 2005 at 20:55:42, Uri Blass wrote: > >>On January 12, 2005 at 20:33:25, Dann Corbit wrote: >> >>>On January 12, 2005 at 20:25:24, Uri Blass wrote: >>> >>>>On January 12, 2005 at 19:56:25, Dann Corbit wrote: >>>> >>>>>On January 12, 2005 at 19:37:29, Steve Maughan wrote: >>>>> >>>>>>Dann, >>>>>> >>>>>>>Things that seem impossible quickly become possible. >>>>>> >>>>>>I recon about 300 years before a computer will solve chess. This assumes >>>>>> >>>>>>1) 10^120 possible positions >>>>> >>>>>This is far, far too large. Chess positions have been encoded in 162 bits, >>>>>which puts an absolute upper limit at 10^58 (and it is probably much less than >>>>>that). >>>>> >>>>>>2) Alpha-beta cutting this down to 10^60 sensible positions >>>>> >>>>>The incorrect first assumption renders this and all following assumtions as >>>>>moot. >>>> >>>>The second assumption is also not correct. >>>> >>>>By the same logic alphabeta can cut less than 2^30 positions in KRB vs KR to >>>>2^15 positions but it does not happen and solving some KRB vs KR position with >>>>no KRB vs KR tablebases is not something that you need 2^15 nodes for it. >>> >>>No. The second assumption would be true if the first was true. This was >>>formally PROVEN by Donald Knuth. In a perfectly ordered alpha-beta solution >>>tree, the number of nodes is proportional to the square root of the nodes in the >>>full tree. >> >>The problem is that the number of nodes in the full tree is bigger than the >>number of positions because the same position can happen in many branches of the >>tree. >> >>Even with perfect order of moves you cannot solve KRB vs KR by alpha beta with >>sqrt(2^30) nodes. > >That is a very good point. > >However, we do not store the nodes simply in a tree but in a transposition >table, the same as we do today. So we do not have to search the nodes over and >over that we already searched. If this is the case then why cannot program solve KRB vs KR without tablebases even with 2^25 nodes(it is known that programs cannot see mate in 50 in relevant positions even with 1024*sqrt(). You can claim that the constant is very large but my guess is simply that there is no constant and all the assumption including the assumption of good order of moves collapse when you search deep and my guess is that one of the problems is that after many plies the order of moves is not good because there were good moves that did not cause cutoff only because they were not searched deep enough and now they cause a cutoff. Uri
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.