Quiesce with no captures and mate in one

[Kempelen]

When enter in the quiesce func and there are no captures, but there is a mate in one (i.e. with a kight), how must we act? generating all moves? or is there any way we can solve this problem?

[gladius]

There are different theories on how to act here. One is to have captures only in the q-search, so it ignores mates and checks. This means that if you can't resolve a check by capturing, the q-search should return the stand-pat value (eval). Another option is to not allow standing-pat if in check, which will treat those situations as mate. This will lead to errors in search either way, but no search is perfect.

Another philisophy is to handle checks in the q-search, so programs have specific check escape move generators, and those moves are searched without a stand-pat cutoff allowed.

Finally, some q-searches also generate moves that cause check, under the theory that the position is not really quiet if the king is under threat somehow. This can easily cause q-search explosion, so you have to be very careful about how many checking moves you allow to be generated, and which ones you pick.

[Gerd Isenberg]

When enter in the quiesce func and there are no captures, but there is a mate in one (i.e. with a kight), how must we act? generating all moves? or is there any way we can solve this problem?

Quite Checks in qsearch may be enabled if you enter a qnode after nullmove. Then you may detect mate-threats after nullmove at lowest depth you allow null, to enable further quite checks to some extend in qsearch for the mate threatening side.

Another option is implementing mate at a glance in eval, e.g. for some common mate-motives like base-rank mates or mates with queen against the king. If kings have less than three escape squares, they may vulnerable on distant checks by sliding pieces if the max two escape squares share a common line, see
http://chessprogramming.wikispaces.com/ ... ttern#toc5

Gerd

[hgm]

How would you know if there is a mate-in-1? Seems to me the purpose of search is to find this out.

I count myself already luck if I know I am in check in a QS node (this is still reasonably easy to figure out, as the last move must have done it). In that case I extend for the evasion. But to know if you can check (and through which moves) is far more expensive. To know if you can checkmate even more so.

[Uri Blass]

How would you know if there is a mate-in-1? Seems to me the purpose of search is to find this out.

I count myself already luck if I know I am in check in a QS node (this is still reasonably easy to figure out, as the last move must have done it). In that case I extend for the evasion. But to know if you can check (and through which moves) is far more expensive. To know if you can checkmate even more so.

The purpose of the search is to find it out and the Quiesce is part of the search.

You have 2 ways to find it out faster relative to Quiesce with only captures.

1)Quiesce that include checks in the first plies
2)Deciding that at small depth you use some type of selective search and search only checks and captures and promotions and maybe some other interesting moves(like pawns go to the 7th).

Both may be equivalent and the question is simply how to define Quiesce.

Uri

[Kempelen]

This can easily cause q-search explosion, so you have to be very careful about how many checking moves you allow to be generated, and which ones you pick.

Talking about qnodes, what is a good qnodes/nodes ratio in average? when a qsearch is considered "explosed"? My engine, from initial position and "sd 6", give 100.358 nodes and 104.456 qnodes, only with alpha-beta and pv and history sort. that sound good? (to my look that qnodes are a lot but not sure)
thx

[Harald Johnsen]

I don't know if we can compare between engines. Some number fo Cyrano 0.4 (note that my node numbers is *not* accurate).

This is with lot of things disabled (no null move, no lmr, no futility pruning, no pruning in QS) :

Code: Select all

info depth 6 seldepth 12 score cp 2  time 4 nodes 21655 pv e2e3 e7e6 b1c3 b8c6 f1c4 f8c5
# Hcut=1077 0 97.4 99.8 38.1 lmr=0 lmrr=0/0 (0.0) FP=0 FPQS=0 sib=0 rec=0 K=4757 reS=9 inQS=17589 (0,21641,8334) s=0
# n.pv=15 pv.s=394 all=743 int=19908 a_cut=15 b_cut=2225 iid=0 (0) nm1=0 nmb=0 nmr=0 ex+=79 fm=0 nmthr=0 ttm=0 recog=0 f_det=2 f_play=1

This is the 'normal' search :

Code: Select all

info depth 6 seldepth 10 score cp 2  time 1 nodes 6602 pv e2e3 e7e6 b1c3 b8c6 f1c4 f8c5
# Hcut=507 0 96.9 99.6 38.1 lmr=2285 lmrr=172/2285 (0.0) FP=2318 FPQS=189 sib=0 rec=0 K=2013 reS=9 inQS=4811 (0,6416,3092) s=0
# n.pv=15 pv.s=394 all=274 int=7948 a_cut=15 b_cut=989 iid=0 (0) nm1=0 nmb=0 nmr=0 ex+=40 fm=0 nmthr=0 ttm=0 recog=0 f_det=3 f_play=1

inQS = number of qs nodes (counted at the entry of QSearch)
FP = number of futility pruning cut
FPQS = same but for QS
nm1,nm2 = number of null moves tries (but i don't to NM in the first 6 plies anyway).
reS = number of re-search
Hcut=x 0 y z ; x = number of transposition tabel cut, y = % of cut on first move tried, z = % of cut in the first 5 moves

Also note that in the pv I am sorting my moves by looking at the hash table values, this is why i have an apparent high % of cut in the first move. I don't use history numbers anywhere.

I hope that does numbers can help you.

HJ.