Winboard Forum

OK, I guess all of us who use selective searches sometimes find inconsistent searches when modifying score based on the hash tabel. Somethign I have done in my progra for one of these is as follows:

I save alpha to a local variable on entry to search.
If I end up raising alpha from a hash table entry, I set a "raised" flag.
If after searching all the moves, I find the best score is less than the new value of alpha, and that I had raised alpha from a hash table entry, I restore the original alpha, then research the moves.

This has helped in specific positions, but I have never been able to prove it makes a difference in playing strength.

Does anyone else do something similar?

Mark

Hi Mark,

What you are doing is similar to my latest idea: In the aspiration search -- for the first fail-high/low -- I re-search with a widened non-failing bound by an amount (currently 35) instead of by 1. It certainly helps resolve fail-highs/lows faster and it helps solve some test positions faster, but I'm not sure if it adds any playing strength. In fact, I'm worried it might take away strength if the search is interrupted at the wrong time. I'm currently testing this idea.

Ron

mjlef wrote:OK, I guess all of us who use selective searches sometimes find inconsistent searches when modifying score based on the hash tabel. Somethign I have done in my progra for one of these is as follows:

I save alpha to a local variable on entry to search.
If I end up raising alpha from a hash table entry, I set a "raised" flag.
If after searching all the moves, I find the best score is less than the new value of alpha, and that I had raised alpha from a hash table entry, I restore the original alpha, then research the moves.

This has helped in specific positions, but I have never been able to prove it makes a difference in playing strength.

Does anyone else do something similar?

Mark

Hi Mark,

your idea is new to me. I simply don't raise alpha from hash. With PVS, pv-nodes with open windows are quite rare - therefor i think it is not that performance critical but probably safer and/or more stable. But the observation per se seems interesting - a hint from hash, that this node was a cut-node before - but the new search didn't cut (or even raise alpha) and parent's designated all-node suddenly cuts.

We may have the "minimal-tree" node-types, passed recursively through the search - we may have the node-type after probing hash. If there is already a let say cut/all discrepancy with appropriate bounds - may be already time to define more node-types, {Pv,Cut,All} X {some weak-strong scale}? Maybe time to be carefull with cuts from hash if sufficent draft and carefull with nullmove? With (some) discrepancies it is probably better to extend rather than to reduce?

If we find a further node-type-discrepancy after searching this node - we may at least consider this while storing the new hash entry - also if a designated all-node is about to get pruned by nullmove. With "extended" node types, we may also try a "safer" multi-cut pruning, e.g, ony for "strong" cut-nodes.

Cheers,
Gerd