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
problems extending hashing from search to qsearch
Moderators: hgm, Rebel, chrisw
-
adams161
- Posts: 626
- Joined: Sun May 13, 2007 9:55 pm
- Location: Bay Area, CA USA
- Full name: Mike Adams
-
Onno Garms
- Posts: 224
- Joined: Mon Mar 12, 2007 7:31 pm
- Location: Bonn, Germany
Re: problems extending hashing from search to qsearch
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)?
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)?
-
hgm
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: problems extending hashing from search to qsearch
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.
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
To my experience hashing QS only makes sense if you allow checks in QS.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.
Ed
-
adams161
- Posts: 626
- Joined: Sun May 13, 2007 9:55 pm
- Location: Bay Area, CA USA
- Full name: Mike Adams
Re: problems extending hashing from search to qsearch
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
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