Exact TT scores and alpha/beta

[syzygy]

But I notice that that seems to be wrong - and at a PV node one should only return an exact score if it lies within the current alpha/beta window.

No, the logic is not quite that. The implication goes only one way: If he minimax score of the node lies within the current alpha/beta window, then the function must return it. Otherwise, it only needs to return something beta or above if the minimax score is beta or above, and something alpha or lower if the minimax score is alpha or lower.

I don't think the last sentence is fully accurate. If the minimax score is >= beta, then the value returned must indeed be >= beta, but it should also be <= minimax_score. This is because the value returned will normally be stored in the TT as an upper or lower bound for the parent node. To replace alpha or beta as a valid bound on minimax_score, the value returned should lie between alpha or beta and minimax_score.

[AlvaroBegue]

But I notice that that seems to be wrong - and at a PV node one should only return an exact score if it lies within the current alpha/beta window.

No, the logic is not quite that. The implication goes only one way: If he minimax score of the node lies within the current alpha/beta window, then the function must return it. Otherwise, it only needs to return something beta or above if the minimax score is beta or above, and something alpha or lower if the minimax score is alpha or lower.

I don't think the last sentence is fully accurate. If the minimax score is >= beta, then the value returned must indeed be >= beta, but it should also be <= minimax_score. This is because the value returned will normally be stored in the TT as an upper or lower bound for the parent node. To replace alpha or beta as a valid bound on minimax_score, the value returned should lie between alpha or beta and minimax_score.

Correct. Sorry for my imprecise language (or my sloppy thinking).

[op12no2]

Yes, sorry chaps, ignore me, >= beta makes sense and that's what I do - no idea what went on in my mind for that message yesterday

[voyagerOne]

Strangely doing PV TT-cutoffs in Stockfish causes a huge regression.

[Evert]

Strangely doing PV TT-cutoffs in Stockfish causes a huge regression.

You make the cut-off under the assumption that searching the node again would give you the same result as you found before, thus wasting time. Stockfish makes pruning decisions based on more than just alpha-beta bounds and depth, so you need to test more than just alpha-beta bounds and depth to decide to accept a cut-off or not. Or you just don't accept it and avoid the complication.

[voyagerOne]

Strangely doing PV TT-cutoffs in Stockfish causes a huge regression.

You make the cut-off under the assumption that searching the node again would give you the same result as you found before, thus wasting time. Stockfish makes pruning decisions based on more than just alpha-beta bounds and depth, so you need to test more than just alpha-beta bounds and depth to decide to accept a cut-off or not. Or you just don't accept it and avoid the complication.

Well said!

[hgm]

What else is there, other than the search window and the depth? How wide the window is?

[Henk]

Lazy evaluation. Adding random values to insure it is not playing same game.

[voyagerOne]

Another test I did was to see if we can safely do an exact TT-Cutoff in QS-Search.

Again it regressed pretty bad..

[Stan Arts]

What else is there, other than the search window and the depth? How wide the window is?

One issue of search with agressive reductions and such is that score becomes more accurate the more often you research a node. For example because hashtable moves are not reduced.

In Nemeton I deliberately close down the root window completely after the first move was searched. I used to have it open 1/6th pawn or so to avoid annoying researches when flipflopping between close moves but the annoying research on any fail high actually increases quality of play.. And Nemeton barely even reduces. I'm sure this effect is much worse in other engines.