problems extending hashing from search to qsearch

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
adams161
Posts: 521
Joined: Sun May 13, 2007 7:55 pm
Location: Tacoma, WA USA

problems extending hashing from search to qsearch

Post by adams161 » Sat May 26, 2007 8:10 pm

HI,

I've been hashing in search for years with no problems. I recently extended hashing ( i hash beta cutoffs and fail high and fail low on alpha and return the new alpha from the hash table when alpha between beta and alpha, well i extended hashing to qsearch. The rpoblem is its getting false mate reports now and then. Are there any special rules for hasihng in quiescent search? I've got null move turned off right now. Also i'm sticking to the rule if the hash depth is > than the search depth.

thanks
Mike

User avatar
Onno Garms
Posts: 224
Joined: Mon Mar 12, 2007 6:31 pm
Location: Bonn, Germany

Re: problems extending hashing from search to qsearch

Post by Onno Garms » Sat May 26, 2007 10:13 pm

For me, hashing in qs caused a slowdown, because it only prunes small portions of the search tree and the cost of lookup is large.

Of course it's hard to guess which but you have intoduced that produces false mate claims. Do you store mate distance relative to the stored position (rather than the root node)?

User avatar
hgm
Posts: 23729
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: problems extending hashing from search to qsearch

Post by hgm » Sun May 27, 2007 6:10 am

It should make little difference if you hash from normal search or QS. In Joker these aren't even different routines.

You should be careful, though, that in QS you do not always have a move to store in the hash even in a beta node, namely if you prefer to stand-pat. And that the hash move you find on a probe (if the bound is not satisfactory, so that you cannot prune) might not be a capture, and so not acceptable in QS.

ed

Re: problems extending hashing from search to qsearch

Post by ed » Sun May 27, 2007 9:13 am

Onno Garms wrote:For me, hashing in qs caused a slowdown, because it only prunes small portions of the search tree and the cost of lookup is large.
To my experience hashing QS only makes sense if you allow checks in QS.

Ed

adams161
Posts: 521
Joined: Sun May 13, 2007 7:55 pm
Location: Tacoma, WA USA

Re: problems extending hashing from search to qsearch

Post by adams161 » Sun May 27, 2007 11:29 am

hi,

I got it all fixed. some problems with hashing before alpha and beta was set apparently which led to the big problem of something writing to the root scores when it shouldnt.

With regard to checks, this is an atomic chess program ( it plays regular chess but this search and qsearh function only deals with atomic, icc's wild 29, chess) I do allow some more interesting checks in qsearch as far as whats interesting in atomic.

I allow a connected rook king or rook queen check in qsearch. i.e. rook adjactent to the king. In atomic the king cant capture because any capture blows up the capturing piece. So these checks are important as te king has to move out of the way or somehow have one of its pieces caputre a piece adjacent to the rook but not the king in which case the rook as a periphia piece is destroyed.

yours
Mike

Post Reply