Author: Tord Romstad
Date: 02:24:29 05/06/04
Go up one level in this thread
On May 05, 2004 at 14:35:10, Vasik Rajlich wrote: >Well, for KQKR I'm sure you can in a few hours come up with something effective, >even at low search depths. However, for things like KRPKR and KPPKP, tablebases >are a really nice solution that you won't easily replace. It's funny that you bring up KRPKR as an example, because I already have a specialized KRPKR eval which works reasonably well in practise. It recognizes some of the most basic won or drawn positions (including the Philidor and Lucena positions), and also has some of the heuristic knowledge you will find in rook endgame books (king on the short side, rook on the long side, using the rook to cut off the defending king, etc.). It is nowhere near perfect, but it is good enough to have saved a huge number of half points against other engines in my test matches. Implementing it took a few days rather than a few hours, though. >Note also that 20 elo points is nothing to scoff at. Perhaps not, but 20 Elo points is a *very* generous estimate of the improvement provided by tablebases. The data I have seen indicate that the strength improvement is hardly noticable. >If you speed up your engine >by 40%, that's about what you'll gain, and we've seen how far some people will >go to get this. You're probably at the point with Gothmog where you'll happily >work for a month to get a ten-point increase. A "month" is not a very precisely defined term when it comes to chess programming. Like all other amateurs, I don't always have the opportunity to work equally much. During some months, I hardly find any time to program at all, but it also happens that I work 10 or 15 hours per month. With something like 15 hours of programming and 20 days of CPU time, a ten-point increase isn't hard to achieve with an engine at Gothmog's level. There are so many pieces of missing knowledge, so many search and eval weights to tune, and so many stupid bugs to fix. >Re. the aesthetics, you can also think of tablebases as far more general than >any heuristics you'll come up with to replace them. The tablebase code knows >only about mates and draws, and its search figures out the rest. It's just an >implementation detail that you precompute the results. :-) It is not entirely accurate to say that I precompute the results. The results have been precomputed by Nalimov's code, which I don't even understand myself. This is another reason why I prefer not to use TBs. Tord
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.