Author: David Rasmussen
Date: 03:37:25 11/27/02
Go up one level in this thread
To elaborate a bit further on this bug: Actually, what _always_ happened before, in _each_ qnode, was that, if n interesting moves to try, were found, the ones with the highest (equal score), were tried in succession, but several times, as the loop would always go n times, unless there was a cutoff! The size of this bug puzzles me... It really proves to me, that qsearch can be idiotic, and you can still have a strong program. Here is an example: If these moves (with scores) were found during interesting move generation Nxf2 (1000) Nxh2 (1000) Nxe3 (3000) Bxe3 (2000) Bxd7 (2000) Rxa1 (1000) Rxb2 (3000) the two moves with score 3000, would tried alternately, until the loop had run 7 times, as there are 7 moves. So the would go like this: Nxe3 Rxb2 Nxe3 Rxb2 Nxe3 Rxb2 Nxe3. Searching the exact same subtrees every time, of course! In a situation where there is only one move with the highest score, it would be tried n times!! In general, only the moves that scored highest, were tried. In this happened recursively, of course... Only if all n moves had the same score, all moves would be tried in succession exactly once, like normal qsearch. How can a program play chess like this? I guess one of the reasons is that the best move, or one of the best moves, will often (more than 90% of the cases) cause a beta cutoff, so in all these positions, the qsearch would have behaved like a normal qsearch. /David
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.