Correct node counting ?

[lauriet]

I've been reading the old pages on this issue and i am still not clear.
What is the correct way to do the nodes accounting ?

Here is the code of what I think is correct....


In main search:
==============
if times up exit.
if 3 fold draw exit
if depth = 0 then Qsearch
Inc(Nodes) because we are now going to search this node further.


In Q search:
============
Inc(Nodes) this is a leaf node
Score = Eval position
if score >= Beta then
exit
Inc(Qnodes) because we are going to search this node further

[Aaron Becker]

I don't think there's a clear standard for what counts as a node--different engines count differently.

One common, simple approach is "increment the node count whenever you make a move".

[lucasart]

It is not uncommon to wait for TT probing/pruning step, becore incrementing the node counter.

[lauriet]

So what is the definition of a node.....

Is it a position visited that generates more nodes?
do we discount the node if we bail out early ?

If we get to use the TT value then we have visited this node and we have a score for this node so shouldn't we count this ?

[hgm]

The most sensible definition is as the operation that is responsible for most of the time usage of your program. If you have a heavy evaluation, you can count calls to Eval(). In Fairy-Max I count move generations.

[ZirconiumX]

For Dorpsgek I count every call to Search(), and also count calls to QS. These are in separate variables for instrumentation reasons. Ultimately, your mileage will vary. Do what you consider to be most reasonable.

[Sven]

I've been reading the old pages on this issue and i am still not clear.
What is the correct way to do the nodes accounting ?

Here is the code of what I think is correct....


In main search:
==============
if times up exit.
if 3 fold draw exit
if depth = 0 then Qsearch
Inc(Nodes) because we are now going to search this node further.


In Q search:
============
Inc(Nodes) this is a leaf node
Score = Eval position
if score >= Beta then
exit
Inc(Qnodes) because we are going to search this node further

What I do is like this:

In check evasion search:
ASSERT(depth > 0)
Inc(Nodes)
check for timeout, check for draw, probe TT, move loop ...

In QS:
if (in check) delegate to check evasion search
Inc(Nodes)
check for timeout, check for draw, evaluate, check for stand pat, move loop ...

In main search:
ASSERT(depth > 0)
if (in check) delegate to check evasion search
Inc(Nodes)
check for timeout, check for draw, probe TT, do pruning stuff, move loop, ...

So basically I increment the node counter once per makeMove (but not inside of makeMove() itself), with the obvious exception of those few makeMove() calls that might be needed for legality checking only.

The "delegate to check evasion search" can of course be improved by detecting whether a move will give check before actually making it, thus saving some recursive calls. Doing so would also simplify my answer: I could just say I increment the node counter whenever I enter one of my search functions for check evasion, QS, or main search.