Author: Scott Gasch
Date: 10:44:33 11/30/00
Go up one level in this thread
On November 30, 2000 at 03:54:37, Bruce Moreland wrote: : >> >>>Monsoon With SEE >>>1 45 109 > >Here we go, right away. Why twice as many nodes in the first ply? You can dump >this tree and find out. Is it doing a stupid move first? If so, why? > Hi, I found a bug... the problem was I was computing a stand pat score in qeval by calling eval. The eval had lazy code after material and pawn hash hit that said: if score so far + WINDOW < alpha, return alpha if score so far - WINDOW > beta, return beta (WINDOW = 2 pawns) But this was pretty new code so in my qsearch I had written it assuming a real eval score. My futility pruning was based on the stand pat (eval) score, not the true material balance. So I was doing a lot of futile captures when, say, we're a queen down but eval returned a lazy bound. I'm sure there are a lot more bugs in there but here are the new numbers in the same position: 1 83 f1b5 2 1005 f1b5 c7c6 b5a4 e5d4 d1d4 3 2202 d4e5 d5e4 b1d2 4 7497 d4e5 b8c6 b1c3 d5e4 c3e4 c6e5 d1d8 e8d8 5 21812 d4e5 d5e4 b1d2 b8c6 f1b5 6 94954 d4e5 g8e7 e4d5 d8d5 g1f3 b8c6 7 376746 e4d5 d8d5 g1e2 f8b4 b1c3 g8f6 d4e5 d5e5 8 1320900 d4e5 d5e4 d1d8 e8d8 b1c3 f8b4 c1g5 d8e8 f1b5 b8d7 e1d2 b4c3 b2c3 Bruce, the 83 looks reasonable... I traced through a 2 ply seach and move order is correct as is the behavior of the qsearch. With the 46 number before I think my qsearch was just broken(?). Thanks, Scott
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.