Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Crafty bug? (18.12)

Author: Robert Hyatt

Date: 11:54:06 10/19/01

Go up one level in this thread


On October 18, 2001 at 14:44:35, Rafael Andrist wrote:

>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


It is doable, but I didn't want to make it _that_ slow.  IE can the king
_really_ reach the promotion square first, which means that it would be
necessary to check several squares for a path.  That sounded like a tree
search so I let the tree search do it. :)



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.