Author: Rafael Andrist
Date: 07:47:50 10/18/01
Go up one level in this thread
On October 18, 2001 at 08:51:56, Robert Hyatt wrote: >On October 17, 2001 at 17:49:39, Robert Hyatt wrote: > >>On October 17, 2001 at 13:05:35, Roy Eassa wrote: >> >>>On October 17, 2001 at 13:02:34, Robert Hyatt wrote: >>> >>>>On October 17, 2001 at 11:15:12, Robert Hyatt wrote: >>>> >>>>>definitely a bug of some sort... >>>> >>>>A pretty simple bug in fact. I just fixed it in the 18.12 source and >>>>re-copied the source to the ftp machine. If you want to try the fix, >>>>feel free. There was a bad calculation that failed when the king was within >>>>one square of the rook-file promotion square, and the pawn was within one square >>>>of the promotion square, and the pawn was to move first... >>> >>> >>>Was the bug only in 18.12, or was it also in previous versions? >> >> >>Been there a while... Nothing has been changed here for several versions. I >>am completely rewriting the EvaluateDraws() code and have changed the name to >>EvaluateWinner(). It returns a bitmask of two bits, 01 means white can win >>only, 10 means black can win only, 11 means either can win, and 00 means dead >>drawn. >> >>It also recognizes a few more cases. I temporarily deleted the 18.12 source >>as I want to fix this completely as part of the final 18.12 release. I hope to >>finish it tonight... > > >New version is now available. It at least handles the test position for this >thread correctly. The search is more "stable" in the endgame as well, now. Did you include this KBP-KP case or did you only fix the bug in the evaluation of KBP-K endgames? Do you also handle cases, where the defending king is near enough, but can be forced to go away? E.g. [D]5k2/8/3K3P/8/8/8/2B5/8 w - - 0 1 regards Rafael B. Andrist
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.