Author: Robert Hyatt
Date: 17:22:42 05/31/99
Go up one level in this thread
On May 31, 1999 at 18:38:10, David Eppstein wrote: >On May 31, 1999 at 15:40:25, Dave Gomboc wrote: >>The hunk of code that was posted tries to get Crafty to promote sooner instead >>of diddling around. But, you don't want to promote by mistake when it's not a >>very good idea, so it (presumably) has some logic that says "if the position I >>am promoting to seems to be not completely winning, I'd better hold off on >>promoting for a bit". > >Close, but I think this is not quite accurate. >First, I didn't actually post the hunk of code, just the description of it. > >But the idea is: if your tablebase says you currently have a win in 14, then it >must be because there exists some move that is a win in 13. That move is the >right move. Any move to a win-in-14 or longer position is wrong, and repeatedly >making wrong moves will turn a win into a draw by the 50-move rule. So you want >to maximize your chances of making the right move even when some of the >tablebases are missing. Although you might not be able to tell which move is >right (because of the missing tablebases), you can use the remaining tablebases >to tell you that some other moves are definitely not right. > >So, at the root of the search, if you're currently in a mate-in-n tablebase >position, you completely prune away any move that stays in a tablebase and isn't >mate-in-(n-1), because such a move can never be right. If you found a >mate-in-(n-1) tablebase position, you can make that move. But if you didn't >find a right move in the tablebase, you know that the right move must be one of >the remaining unpruned non-tablebase moves, and you can just do a search among >them. > >There is no test for whether the search returns something completely winning or >not. You just do a search on the unpruned positions and follow what it returns. > >The intent is that you only remove tablebases when you trust the search to find >the right move for you. E.g., in the example I posted, there is no need to >store the KQKN tablebase, because Crafty can always win that endgame easily >without a tablebase, and even a fairly shallow search can generally (always?) >identify the weird situations when you need to underpromote or something instead >of going into that endgame. I will only add one comment, because I don't consider any of this to be a big issue: if you don't get them all, you drastically hurt search performance. Because crafty probes when it trades down to a 5 piece ending. If the file is not there, the probe is _not_ free. It slows things down measurably. Additionally you are assuming that the P is the issue, but what about the cases where there is no P to start with? IE where you just hit a KQ vs KN position directly without going thru KP vs KN? 6 gigs is now trivial. You can buy an 18 gig disk for 200 bucks and this is all totally moot. One serious principle of software engineering is "keep it simple, stupid" (KISS principle). You can burn hundreds of dollars worth of programming time to save less than 100 dollars (since you have to store the P files anyway, and they are _far_ larger than the non-P files you are eliminating.)
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.