Author: Uri Blass
Date: 02:21:11 06/27/03
Go up one level in this thread
On June 27, 2003 at 03:59:29, Tom Kerrigan wrote: >On June 26, 2003 at 22:45:17, macaroni wrote: > >>I recently wrote a computer chess program, using alpha-beta, null moving, and >>quiescent search, in the main search function I use a history heuristic to sort >>moves, and that seems to be doing just fine, I can't say the same for my q >>search, the sorting procedure I use for that, is biggest capture, smallest >>attacker. However, when I do a ply 5 search, i get 23,000 standard search nodes, >>which seems acceptable to me, but I get 180,000 q nodes, which seems ridiculous. >>Is this as bad as I think it is? is it expectded? should I just make my Eval, >>MoveGen, MakePosition and UnmakePosition functions faster (if possible)? Also, >>my program manages 75,380 nodes per second, is this high? someone once told me >>that a high node/sec count is not always good. >>Thanks everyone > >An 1:8 full-width nodes:quiescent nodes ratio is not unusual if you're just >searching captures and using the move ordering you describe. If you think about >it, it isn't that ridiculous. You have to call qsearch at every leaf node, and >most full-width nodes are leaf nodes, so the smallest ratio you can see is >pretty much 1:2, and from there, if you think about how many captures each leaf >node is likely to have... > >-Tom It seems that I define quiescent nodes in a different way. For me not every leaf node is a quiescent node and a node is a quiescent node only if it happens after a capture(or another move) that was generated in my qsearch function. Uri
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.