Author: Robert Hyatt
Date: 10:50:32 09/26/99
Go up one level in this thread
On September 26, 1999 at 10:33:03, James Flanagan wrote: >I am a relatively new user of Crafty, and am using it in the Kasparov v. World >game. Our strategy seems to be to go for a draw, while GK's strategy is >presumably to avoid the draw and go for a win. I've had some difficulty >implementing this strategy using Crafty, which I am using through the Winboard >interface. Here are two questions and observations about my recent experiences >using Crafty 16.19 + all available tablebases in the Analysis Mode: > >1. When the Winboard Analysis window shows an evaluation of 0.00 ... <EGTB>, I >initially thought that this "guaranteed" a draw. I now come to realize (after >some public embarassment) that the draw is not "forced," and either player can >often bypass the draw by making a move other than the ones shown. I've tried >manipulating the "contempt" function using the "drawscore -50" suggested in the >crafty.doc file, but this is not always successful in bypassing avoidable draws. > Any suggestions as to how I can better tune Crafty to implement the World's >strategy? > all you can do is set the draw score very high. Then crafty will search for ways to make it happen, and it will assume that Kasparov will try to avoid it since the score is so big. IE go for drawscore=500 and see what happens. If it says draw there, it likely is forced, as it would take a truly huge score to overcome that... >2. I also found that Crafty doesn't immediately recognize draws by repetition >of position by infinite check. It would seem that such a recognition function >could easily be incorporated by looking for closed loops between recent >positions. If these could be recognized instantly, they could be handled >similarly to <EGTB> draws. don't know what you mean there. It does this easily. Unless you don't feed in the entire game move list, and use a FEN setup string. That hurts the draw detection since it doesn't know anything about prior positions. But basic repetitions are caught easily (look at RepetitionCheck() code in repeat.c) > >3. I am not current with the computer chess literature, but it would seem that >the situation described in #1 could be handled by a type of "asymmetrical >alpha/beta" approach. This approach would use different evaluation criteria for >each side. (An interesting extension would be to consider the case in which the >players don't have perfect knowledge of the opponent's eval functions). Does >anyone know if such a system has been described theoretically, and if so has it >been implemented in any current chess software? that's what the 'drawscore=500' accomplishes... it makes the draw scoring logic highly asymmetrical and will do what you want. > >Thanks for any insight that you can share. >Jim Flanagan
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.