How to determine NPS

[EricLang]

I was wandering: what is the most precise way to count the nodes searched?
Now I increment the nodes at:

- each AlphaBeta procedure call
- each move done during AlphaBeta
- eachQuiesce procedure call
- each move done during Quiesce

Should I increment it at each Evaluate procedure call too?

NPS is lower when using hashtables, but this is unfair because I do *not* have to generate moves and thus save time, so this "equals out".

[Aleks Peshkov]

You may count nodes anywhere you like, but it is better to increment counter once and only once per each node.

Transposition Table save nodes, not time.

[ernest]

Transposition Table save nodes

Why?
I thought they mainly save evaluation time.

[EricLang]

Let me rephrase then
What exactly can we say is a node?

[CRoberson]

Let me rephrase then
What exactly can we say is a node?

Add one at the beginning of each search: Search and Quiesce count.
Don't add one at eval unless you skip counting Quiesce.

[Edmund]

Transposition Table save nodes

Why?
I thought they mainly save evaluation time.

It saves you from searching the children nodes of a certain position a second time, if you have done so before. (in case of transpositions)
Or gives a hint where to start the search (transposition table move), thus improving moveordering and achieving an earlier cutoff.

In both cases you have to search less nodes, but still, due to the lookup of the Transposition table the time spent at the specific node increases. So Nodes/Time decreases.

And keep in mind that you will get a lot of Transposition table misses as well, where you are requesting an entry from the RAM (which takes some time), to find out that you haven't visited the position before.

[hgm]

I count calls of Search() (which is the same as Quiesce() ). This gives a non-standard count, though, as Search is not called for nodes that are found in the transposition table (with sufficient depth and OK bounds), as I probe the hash before doing MakeMove.

[Sven]

Let me rephrase then
What exactly can we say is a node?

It is quite simple. The search tree consists of nodes and edges. Nodes represent positions and edges represent moves. Each move connects two positions, so each time we make a move we visit a new node, regardless what the search algorithm does there, regardless whether we continue the search or decide for any reason that the current node is a leaf node. So there are cheap nodes (e.g. TT hits, some draw positions), medium expensive nodes (e.g. illegal positions) and expensive nodes, but all of them are nodes.

Following this simple rule should help to figure out easily where to increment the node counter in each individual search implementation.

EDIT: Each iteration of the search traverses a completely new search tree, so all of its nodes should be considered as new nodes, too, even in case of hash hits.

Sven

[Steelman]

Let me rephrase then
What exactly can we say is a node?

Add one at the beginning of each search: Search and Quiesce count.
Don't add one at eval unless you skip counting Quiesce.

I would think you are right.
All search and qsearch calls
no calls to eval should be counted
do not count transposition table hits (they are like a call to eval)

[Cardoso]

How about counting only at a single place: MakeMove() ?

Alvaro