Author: Omid David
Date: 03:30:02 10/04/02
Go up one level in this thread
On October 03, 2002 at 22:47:58, Jeremiah Penery wrote: >On October 03, 2002 at 22:07:38, Omid David wrote: > >>On October 03, 2002 at 21:30:56, Jeremiah Penery wrote: >> >>>On October 03, 2002 at 20:39:02, Omid David wrote: >>> >>>>Quite impressive, just 1.02% slower (paractically negligible). Do you invoke >>>>that detection at every node in the search tree? >>> >>>Yes, but most of the time it exits very quickly (a couple of 'if' clauses). I >>>could probably make it cost even less, but I'm not very interested in doing that >>>yet. >> >>But the problem may arise in the endgames where there are a number of pawns and >>pieces left which can potentially cause a "block draw". Then in the draw >>detection heuristic, almost in every node you'll pass the first few 'if's and >>will have to step into a detailed assessment of the position. How much does it >>slow down there, in comparison to the non-detecting version? > >I'm not really sure, and I suspect it depends highly on the kind of position. >If you have any specific ones, I'll be happy to test them. > Let's compare the following two very similar positions: The first one - White wins: [D] 8/8/8/k3p3/1p1pPp2/1PpP1P2/K1P3B1/8 w - - 0 1 The second one - Draw: [D] 8/8/8/k3p1p1/1p1pPpP1/1PpP1P2/K1P3B1/8 w - - 0 1 How do the different methods fare in these two cases?
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.