Transposition table bug - Points to incorrect alpha-beta?

[bob]

depth = remaining plies before calling Quiesce(). In Ken's original post of the negamax algorithm, he did this:

if (depth > 0)
v = -Search(..., ply+1, depth-1)
else
v = -Quiesce(..., ply+1, depth-1)

And most have written their code that way.

But Heinz did this:

if (depth >= 0)
v = -Search(..., ply+1, depth-1)
else
v = -Quiesce(..., ply+1, depth-1)

I think you are wrong here, see Heinz' "Extended Futility Pruning" paper:
http://people.csail.mit.edu/heinz/dt/node18.html
http://people.csail.mit.edu/heinz/dt/node22.html

The well-known technique of futility pruning at frontier nodes (depth = 1) exploits the peculiarities of ``standing pat'' at horizon nodes (depth = 0). ``Standing pat'' means to compute the static evaluation score of a node in order to test it against the upper search bound for a possible fail-high beta cutoff without further lookahead. Thus, ``standing pat'' implements the null-move assumption during the quiescence search with static node evaluations serving as null-move scores of zero depth. The following two sections describe the theory and practice of futility pruning at frontier nodes in detail because they provide the foundations for our new pruning scheme.

As far as I remember, your problem with Heinz was calling depth=1 nodes frontier nodes ...
http://www.stmintz.com/ccc/index.php?id=387518

My depth=1 is a frontier node. For heinz it was depth=0 so far as I remember. In any case, when I am at depth=1, i do full-width, but always call quiesce unless the move I search is a check which extends depth by 1, which leaves it at 1 for the next ply.

I discovered the difference in our programs not by reading his paper, but by looking at his code.

[Gerd Isenberg]

My depth=1 is a frontier node. For heinz it was depth=0 so far as I remember.

Confusion. From your old posting the other way around:
http://www.stmintz.com/ccc/index.php?id=387518.

Hyatt:
depth == 1 pre-frontier node
depth == 0 frontier node
depth <= 0 qsearch noses

Heinz:
depth == 2 pre-frontier node
depth == 1 frontier node
depth == 0 horizon node

[bob]

My depth=1 is a frontier node. For heinz it was depth=0 so far as I remember.

Confusion. From your old posting the other way around:
http://www.stmintz.com/ccc/index.php?id=387518.

Hyatt:
depth == 1 pre-frontier node
depth == 0 frontier node
depth <= 0 qsearch noses

Heinz:
depth == 2 pre-frontier node
depth == 1 frontier node
depth == 0 horizon node

It could well be backward. It was so long ago I don't remember, I just remember that we had inconsistent definitions that led to confusion on my part. I never have "depth=0" nodes in Crafty. When I get ready to recursively call search and depth==1, I call Quiesce() which matched Ken's original negamax code (as well as the old alpha/beta minimax pseudocode most used as well).

But it works either way. Just means depth means something different (exactly 1 ply different) for each of those two programs. But then again, depth has never been completely consistent, i.e. Junior using ply=3 rather than 1. The depths reported look rather insane, but the results reported are as expected for that particular "number of plies of search".

I actually thought I was explaining it sensibly, because for Crafty, depth=1 was always what Heinz called "frontier". The tree didn't have to go beyond that depth as a static eval and return from q-search would end that branch. For heinz it happened at depth=0 instead. So maybe my explanation was not so clear, as depth=1 -> frontier is obvious in Crafty. Only way a node with depth=1 doesn't go directly to q-search is if one or more of the moves there are checks which increase depth to 2.