Transposition table in PV nodes

[metax]

Why do we use the transposition table for move ordering in PV nodes if we want to search the move from the triangular PV array first anyway?

[hgm]

I don't even have a triangular array in Joker. Why would you want a triangular array if you have a transposition table?

I just implemented a triangular array in Fairy-Max, to have something to print after the search, but the PVs I get from there are very incomplete. PV hits cut them short too often. I should collect some statistics on the number of PV nodes. If there aren't too many, perhaps it would be a good idea to store the complete PV in the hash table with a PV node. Most PV nodes will have low draft anyway, so a pretty short PV. Moves can be encoded in a single byte, and in Joker the hash entries are 9 bytes. S if I reserve 2 entries in stead of 1 for a PV node, it would allow me to store the PV for any PV node with a draft <= 9.

[jwes]

Why do we use the transposition table for move ordering in PV nodes if we want to search the move from the triangular PV array first anyway?

If you stuff the pv into the transposition table at the start of the search, you don't need any special code to handle the old pv.

[metax]

Because at least in my program, I only do a move entry in the transposition table if the search has failed high, which rarely happens. Otherwise I don't even save the best move in the TT. Is this wrong?

[metax]

If you stuff the pv into the transposition table at the start of the search, you don't need any special code to handle the old pv.

Whyt do you mean by 'stuff the pv into the transposition table'?

[Gerd Isenberg]

Why do we use the transposition table for move ordering in PV nodes if we want to search the move from the triangular PV array first anyway?

Even with a triangular PV array most PV-Nodes are not leftmost in practice.

[Gerd Isenberg]

Because at least in my program, I only do a move entry in the transposition table if the search has failed high, which rarely happens. Otherwise I don't even save the best move in the TT. Is this wrong?

Storing Cut-nodes is fine and happens frequently. Anyway you should store PV-nodes as well, despite triangular array. It is also common to store upper-bound scores of All-nodes.

[hgm]

Because at least in my program, I only do a move entry in the transposition table if the search has failed high, which rarely happens. Otherwise I don't even save the best move in the TT. Is this wrong?

Yes, this is wrong. You have a best move whenever score > alpha, and you might as well store it. Because what is a PV node now will become a cut-node when a later side-branch supeseeds the current PV. And in the next iteration you will revisit that cut node, and then you don't have any idea what could be a cut move, while you could have known even which move was best.

Your hash table will contain tens of thousands of PV nodes, and he triangular array only a dozen.

[jwes]

If you stuff the pv into the transposition table at the start of the search, you don't need any special code to handle the old pv.

Whyt do you mean by 'stuff the pv into the transposition table'?

At the start of each iteration, you put the positions in the pv into the hash table, so that getting a best move from the hash table for a position in the pv gets the pv move.

[bob]

Why do we use the transposition table for move ordering in PV nodes if we want to search the move from the triangular PV array first anyway?

Because you ought to have the PV array moves in the TT already. This avoids special-purpose code for PV nodes, and a test that would be false most of the time (is this a pv node? then search this first, else search the TT move first).

Just a matter of efficiency/speed, nothing more.