Author: Rafael Andrist
Date: 11:44:35 10/18/01
Go up one level in this thread
On October 18, 2001 at 14:27:06, Robert Hyatt wrote: >On October 18, 2001 at 14:23:44, Rafael Andrist wrote: > >>On October 18, 2001 at 14:20:39, Dann Corbit wrote: >> >>>On October 18, 2001 at 10:47:50, Rafael Andrist wrote: >>> >>>>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 >>> >>>EPD Kit revision date: 1996.04.21 >>>unable to open book file [e:\crafty\release/books.bin]. >>>hash table memory = 192M bytes. >>>pawn hash table memory = 80M bytes. >>>EGTB cache memory = 32M bytes. >>>draw score set to 0.00 pawns. >>>choose from book moves randomly (using weights.) >>>choose from 5 best moves. >>>book learning enabled >>>result learning enabled >>>position learning enabled >>>threshold set to 9 pawns. >>>5 piece tablebase files found >>>19045kb of RAM used for TB indices and decompression tables >>> >>>Crafty v18.12 >>> >>>White(1): st 60 >>>search time set to 60.00. >>>White(1): setboard 5k2/8/3K3P/8/8/8/2B5/8 w - - >>>1. Bb3 Ke8 2. h7 Kd8 3. h8=Q# >>>White(1): >> >>What do you want to say? It's clear that it is very easy using EGTB. >> >>Rafael B. Andrist > >No egtb's > > > 2 0.00 0.00 1. Ke6 Kg8 > 2 0.00 ++ 1. Bb3!! > 2 0.00 12.04 1. Bb3 Ke8 > 2-> 0.00 12.04 1. Bb3 Ke8 > 3 0.00 ++ 1. Bb3!! > 3 0.00 13.05 1. Bb3 Ke8 2. h7 Kd8 3. h8=Q# > 3-> 0.00 13.05 1. Bb3 Ke8 2. h7 Kd8 3. h8=Q# > 4 0.00 ++ 1. Bb3!! > 4 0.00 Mat03 1. Bb3 Ke8 2. h7 Kd8 3. h8=Q# > 4-> 0.01 Mat03 1. Bb3 Ke8 2. h7 Kd8 3. h8=Q# > 5 0.01 Mat03 1. Bb3 Ke8 2. h7 Kd8 3. h8=Q# > 5-> 0.04 Mat03 1. Bb3 Ke8 2. h7 Kd8 3. h8=Q# Thanks, nearly the same as I get. I was interested if you recoginze it statically as won. As I can see you don't, therefor it is not very dramatically if I don't do it too. :-) 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.