Transposition table pruning
Posted: Wed Nov 25, 2009 1:44 pm
Why isn't the transposition table used for pruning at PV nodes (at least in Stockfish)?
Thanks.hgm wrote:Pruning the PV would print short PVs if you use the triangular-array method, and not pruning might help you to recognize rep-draws that were not accounted for in the hash.
This is very well written. We could add this as a comment in the code.zamar wrote:Values from TT are not used in PV, because:
* Extra cost is small (TT values can be used for non-PV child nodes).
* rep. draws are problemtic (as hmg pointed out)
* fifty move rule detection is problematic
* delivering mate is problematic when TT shows matescores everywhere and would need special handling.
I do not use TT in PV because I like to have a full PV. But, I never had any of the other problems. Why would you have specific problems with mates scores and draws?zamar wrote:Values from TT are not used in PV, because:
* Extra cost is small (TT values can be used for non-PV child nodes).
* rep. draws are problemtic (as hmg pointed out)
* fifty move rule detection is problematic
* delivering mate is problematic when TT shows matescores everywhere and would need special handling.
And a good bit of that is dead wrong as well. Rep draws are problematic _everywhere_, not just along the PV branches. Ignoring the problem in part of the tree is an invitation for really subtle bugs. Ditto for 50 move draw issues. Why would you avoid hash cutoffs on the PV but not elsewhere? You fail high on a second move, and don't have time to re-search it as a PV branch due to time limits, and you make a decision based on hash cutoffs. This idea makes no sense to me whatsoever, and sounds just like the other ideas such as (1) don't store draw scores in the hash table; (2) don't store mate scores in the hash table; (3) Don't store mate bounds in the hash table. Etc...mcostalba wrote:This is very well written. We could add this as a comment in the code.zamar wrote:Values from TT are not used in PV, because:
* Extra cost is small (TT values can be used for non-PV child nodes).
* rep. draws are problemtic (as hmg pointed out)
* fifty move rule detection is problematic
* delivering mate is problematic when TT shows matescores everywhere and would need special handling.
The TT can hide a draw because it doesn't store path information. But this is true of the 50-move rule as well. I certainly do not any justification for not allowing cutoffs from hash along the PV. It is just a hack fix that actually loses significant information. This is critical for finding fine 70 early, as an example.michiguel wrote:I do not use TT in PV because I like to have a full PV. But, I never had any of the other problems. Why would you have specific problems with mates scores and draws?zamar wrote:Values from TT are not used in PV, because:
* Extra cost is small (TT values can be used for non-PV child nodes).
* rep. draws are problemtic (as hmg pointed out)
* fifty move rule detection is problematic
* delivering mate is problematic when TT shows matescores everywhere and would need special handling.
Miguel
I think you missed the word "specific" in my question. What you say is right but not specific for the PV.bob wrote:The TT can hide a draw because it doesn't store path information. But this is true of the 50-move rule as well. I certainly do not any justification for not allowing cutoffs from hash along the PV. It is just a hack fix that actually loses significant information. This is critical for finding fine 70 early, as an example.michiguel wrote:I do not use TT in PV because I like to have a full PV. But, I never had any of the other problems. Why would you have specific problems with mates scores and draws?zamar wrote:Values from TT are not used in PV, because:
* Extra cost is small (TT values can be used for non-PV child nodes).
* rep. draws are problemtic (as hmg pointed out)
* fifty move rule detection is problematic
* delivering mate is problematic when TT shows matescores everywhere and would need special handling.
Miguel