Author: Vine Smith
Date: 03:23:55 05/29/02
Go up one level in this thread
On May 28, 2002 at 20:53:16, bob o wrote: >>>It has been proven a few times that 6-man TBs don't make an engine "smarter", >>it just makes them play a prettier endgame. The 3/4/5's are really the only >>TBs you NEED to have. >> >>I don't see how such a thing could ever be "proven". First, there's the obvious >>fact that as the number of men in the tablebases increases, the engine's game >>must improve, since if it had access to 32-man tablebases, I think it might >play very well indeed. > >The problem, as I understand it, is that the access to the hard drive slows down >the search. So if you had a position where you would get ~500 kn/s without >tablebases, you would only get, say, ~200 kn/s with tablebases. They give more >accurate evaluations for fewer positions, in other words. > >>Second, I fail to see why 5 should be some magic number for the maximum number >of men in the tablebases that are "needed" -- why not 4 or 7 or any other >>number? Just because the 6-man tablebases are not yet complete does not render >them any less necessary than 3-4-5. > >The 6-man files already generated are generally things like krnknn, which almost >never comes up. The ones that would matter more are the ones with pawns, such as >krpkrp, since these occur in real games more frequently. The problem with >generating tablebases with pawns is that you first need all the related ones >without pawns, such as kqrkqr, kqrkrp, krrkrp, etc. > >5 is not seen as a magic number, it's just the largest ones that current >technology allows for. > >As an aside, current checkers programs can use 8-man checkers tablebases (the >files are much smaller than chess tablebases). A fast computer can sometimes >analyze a position that is just out of the opening book, and hit the tablebases >on the first move that it searches. It can then know only a few moves into the >game what the result will be, assuming the other program doesn't blunder. This >helps delete losing book lines and improves the opening book immensely, as I >understand. > >Bob The point regarding hard drive access times slowing the search is quite valid, although I would imagine that this could be substantially decreased by using a larger EGTB cache -- maybe I will do some testing with Crafty to see the effect of, for instance, 4 Mb vs 8 Mb. Also worth testing is performance with no TBs vs. 3 only, 3+4, and 3+4+5, although I suppose this would require very many games, since most are decided much earlier. Presumably, some have already conducted tests of this sort, which is the "proof" Slater was referring to, but I wonder under what conditions these were conducted, and am not sure if it's worth digging through the archives to find them. Even with the slower search, I think more accurate evaluations of fewer positions should be better, since many endgames cannot be solved even by searches 20-30 ply deep. It would seem that unless there are diminishing returns from each increase in the number of men in the tablebases, and 5-man is the last set with a sufficiently positive return versus the slower search, it cannot hurt to add the available 6-man tablebases, except in the well known case of improper interpretation of these by the program, where it refuses to queen a pawn or something like that due to refusal to leave the safety of the tablebase evaluation (but this is just a bug to be fixed, and not a valid argument against using these tablebases). I had run across the checkers tablebases around a month ago during a discussion of this game in another post -- it appears that this last set of recently released 8-man tablebases threatens to practically "solve" the entire game of 8x8 checkers, and there was a site that posted results from some sort of poll predicting in which year 8x8 would be completely analyzed (in terms of best play). As I recall, the year 2005 was the favorite. Regards, Vine
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.