Author: Jeremiah Penery
Date: 16:09:22 10/04/02
Go up one level in this thread
On October 04, 2002 at 18:06:21, Omid David wrote: >On October 04, 2002 at 17:27:05, Jeremiah Penery wrote: > >>On October 04, 2002 at 16:51:38, Roy Eassa wrote: >> >>>On October 03, 2002 at 19:18:16, Jeremiah Penery wrote: >>> >>>>[D]8/7p/6pP/k4pP1/b1p1pP2/KpPpP3/1P1P4/7Q w - - 0 1 >No blockade-detecting algorithm should announce a draw in this position, since >the blockade can be "broken". And I think there might be a victory for white >hidden: > > >1.Qd1 > >A) 1... Kb5 > 2.Qh5 > i) 2... gxh5 > 3.g6 hxg6 4.h7 white winning > ii) 2... Ka5 > 3.Qxg6 hxg6 4.h7 white winning >B) 1...Bc6 (or any other bishop move) > 2. Qxb3 cxb3 3.Kxb3 unclear situation My reasoning is that it's way harder to detect a blockade by search than it is to detect a winning line in some "blockaded" positions. In this position, if Qd1 Bc6 Qxb3 etc. is winning for white, the search will find it pretty quickly. However, without detecting this as a blockade, the program will NEVER detect the draw, and it will shuffle the pieces around forever, while declaring itself winning by 6 pawns or more. Either way, the end result will be a draw. My 'algorithm' is a pretty simple thing. I just wanted it to be fast, and not miss any cases, though I didn't care too much for false cases (because of the above). Unless my thing is 100% correct, and never misses any potential blockade draws, there will be error anyway (without the algorithm, you will say +6 in the position above, and many similar positions, though it is a draw - with the incorrect algorithm, you may say draw in some winning position). If there are cases where my stuff is completely and totally wrong, I will try to fix it. Otherwise, I'll take some inaccuracy and be reasonably happy that it works most of the time.
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.