Checks in Quiescent Search

[Edsel Apostol]

Hi everyone,

How much Elo points a program could earn by generating checks in

quiescent search?

Edsel

[Dann Corbit]

Gain in strength will depend on many factors (including what other sorts of extensions you are doing).

It is also possible to lose strength (for instance, if you do too many checks).

[smcracraft]

Gain in strength will depend on many factors (including what other sorts of extensions you are doing).

It is also possible to lose strength (for instance, if you do too many checks).

I believe Bob starts off his depth at 1.5 and increases by 0.75 for
each checking move that places the other side in check.

This controls potential quiescence check extension explosions.

I am thinking of switching to it.

[Gian-Carlo Pascutto]

Crafty doesn't do checks in the qsearch.

[Volker Böhm]

Hi,

I think from -20 to +20, depends on your engine and the way to implement it. For spike it was a not really measurable elo gain (5-10 Elo) to have checks in the first ply of q-search. Any more plys reduced the strenth.

Greetings Volker

[Uri Blass]

Hi,

I think from -20 to +20, depends on your engine and the way to implement it. For spike it was a not really measurable elo gain (5-10 Elo) to have checks in the first ply of q-search. Any more plys reduced the strenth.

Greetings Volker

I think that it can be probably more than +20 but it is very hard to answer because there are tricks that work only if you have checks in the qsearch and if you remove checks in the qsearch and do not remove the tricks the comparison is not fair.

for example R for null move pruning.

Without checks in the qsearch constant as 3 may be too risky when with checks in the qsearch it is different.

Uri

[L?szl? G?sp]

Hi everyone,

How much Elo points a program could earn by generating checks in

quiescent search?

Edsel

Hi Edsel,

I don't know it by ELO, but I can recall that Anthony Cozzie mentioned once, it is a must. I believe him .

Regards,
L?szl?

[H.G.Muller]

You have to put some limit to it, though: if you generate checks in QS, you also would have to consider check-evasion in order not to score every check as a check-mate, and in some situations this explodes (e.g. in KQK).

A solution to this problem that I used in 1981, and seemed to work quite well, was only allow one check with the same piece in a row, unless the second check is a capture (in that case the move was considered because it was a capture, not because it was a check; other captures with the checking piece would also be considered in QS). If two different pieces were involved in giving a series of checks, this usually led to a quick check-mate.