oddity with triangular PV approach and TT

[Fguy64]

OK I recently fed a bunch of forced mate positions to my engine, under the following conditions

no qSearch, material evaluation only, fixed depth, no iterative deepening, plain vanilla alphaBeta search with hashing enabled for transpositions only. I am displaying PV, for info purposes only, using the triangular array approach

in all cases the correct move and mate score was returned given sfficient search depth. However, in a small percentage of cases, the displayed PV was abbreviated. What was displayed was correct, but it wasn't complete. The rest of the cases (the majority) showed the full sequence of moves, including the final mating move

This situation was remedied by disabling my hash probes. I am at a loss to explain this. It's a little annoying, but I can't see what I am doing wrong. Perhaps it is normal state of affairs? I can show you my code, and some relevant positions, but I figured this must be a known problem.

[hgm]

This is normal. It means you had a hash hit in the PV, that caused a hash cuttoff. The triangular-array method cannot look beyond a hash hit, as you do not store the PV in the hash table with PV nodes. So after the has probe it does kow the score, but it has no idea what sequence of moves lead to it.

Some engines forbid hash cutoffs in PV nodes, to prevent th P truncation. This slows down your search, however, for no benefits w.r.t. move choice.

[Fguy64]

Thanks.

Continuing on with this line of discussion, I have been wondering if there is any value added by using PV arrays when you have iterative deepening using hash moves for PV first searching. Even if that value is just for display purposes. This and other threads have led me to suspect tehre is value, though I haven't yet got round to working it out.

[hgm]

I am not sure if there is value. My engines did not use the tri-angular-array method at all, until recently. They still rely totally on hash moves. In Joker I peeled the PV out of the hash table afterwards. That does not always give the PV the engine had in mind. E.g. you can have a PV that ends in checkmate, while the score reported with the engine move was not a mate score. Also, when the PV contained a repetition, following it in the hash table always makes it a perpetual repetition, while the engine might not give a draw score, because it actually decided to break out of it in the search.

In micro-Max I could not even peel it out of the hash, as it has a crummy hash table, and the PV would run into an overwritten entry very quickly. So for the benefit of being able to show a PV afterwards, I implemented something in Fairy-Max that is equivalent to the tri-angular-array method. (Except that it uses a linear array.) But it uses that PV in no way during the search. It is just for reporting. And it suffers from the same truncation you complained about here.

But despite all those defects, Fairy-Max is the only WinBoard engine to support multi-PV in many variants. E.g. try to find another Knightmate engine with multi-PV!