Search Inconsistencies

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Search Inconsistencies

Postby mjlef » 23 Jun 2006, 15:35

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
mjlef
 
Posts: 64
Joined: 29 Mar 2006, 22:04

Re: Search Inconsistencies

Postby Ron Murawski » 23 Jun 2006, 19:43

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
User avatar
Ron Murawski
 
Posts: 351
Joined: 26 Sep 2004, 21:50
Location: Schenectady, NY, USA

Re: Search Inconsistencies

Postby Gerd Isenberg » 23 Jun 2006, 19:54

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
Gerd Isenberg
 
Posts: 285
Joined: 31 Jan 2005, 20:31
Location: Hattingen, Germany


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 4 guests