Author: Omid David
Date: 05:03:19 10/04/02
Go up one level in this thread
On October 04, 2002 at 06:30:02, Omid David wrote: >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? And a third position which is also a draw: [D] 8/8/8/k3p3/1p1pPp2/1PpP1P2/B1P5/1K6 w - - 0 1
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.