Author: Robert Hyatt
Date: 13:49:25 03/28/00
Go up one level in this thread
On March 28, 2000 at 13:02:10, Dave Gomboc wrote: >On March 27, 2000 at 23:20:50, Robert Hyatt wrote: > >>On March 27, 2000 at 11:15:23, blass uri wrote: >> >>>On March 27, 2000 at 09:53:57, Ed Schröder wrote: >>> >>>>On March 27, 2000 at 09:06:01, Robert Hyatt wrote: >>>> >>>>>On March 25, 2000 at 23:13:49, Tina Long wrote: >>>>> >>>>>>On March 25, 2000 at 14:28:13, James Robertson wrote: >>>>>> >>>>>>>On March 25, 2000 at 13:41:28, Roger wrote: >>>>>>> >>>>>>>>Would tablebases for Tiger have changed this result at all? >>>>>>>> >>>>>>>>Roger >>>>>>> >>>>>>>Maybe a quarter of a point.... My experience with tablebases is that if the >>>>>>>program is moderately smart it doesn't benefit tremendously from them. >>>>>>> >>>>>>>James >>>>>>> >>>>>>Ed Schroder said about 6 months ago that Tablebases were worth about 10 points >>>>>>on the SSDF scale. >>>>>> >>>>>>I'm 70% sure he said that! I'm 100% sure that Ed said once that something was >>>>>>worth very little rating points. >>>>>> >>>>>>I'm glad I could add some real detail to this discussion. >>>>>> >>>>>>Tina Long >>>>> >>>>> >>>>>Ed is wrong there. it is _amazing_ how many comp vs comp games end up in >>>>>krp vs kr, with the side without tablebases losing most of those. There are >>>>>other endings too (KQP vs KQ, see for example crafty vs nimzo in the ICCT >>>>>tournament last month). >>>>> >>>>>The wrong way to test this is to play A with, vs A without. the right way to >>>>>test this is A without vs B without, then A with vs B without. But A ought to >>>>>be reasonably close to B without tablebases... >>>> >>>>Tablebases have a great future no doubt. But what is available at the >>>>moment (4-5 pieces) its value for Rebel is not more than 5-10 elo I >>>>would say because: >>>> >>>>a) most cases are simply covered by chess knowlegde; >>>> >>>>b) the loss of speed during search because of all the >>>>disc access. >>> >>>I do not think that b is right because you save time by not searching positions >>>of 5 pieces. >>> >>>disc access is relevant only after a capture that leads to 5 pieces on the >>>board. >>>My simple logic says that if you search n plies forward then you can decide to >>>call tablebases only after a capture that leads to 5 pieces and only if the >>>caprure is at distance of n-d plies from the root when d is the minimal numner >>>that searching d plies forward is slower than calling tablebases. >>> >>> >> >> >> >>That is all correct. Disk access is _not_ a problem. It doesn't slow me >>down enough to be a problem at all, and the gain more than offsets the >>I/O time... and if you cache stuff right, and hash the results right, the >>penalty drops to almost nothing for most positions... >> >>And the gain... :) > >Disk access isn't a problem _now_ in Crafty, but it was for a while until you >tuned the implementation, right? > >Dave _everything_ has been a problem _before_ tuning. :)
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.