WAC test

[mcostalba]

but pruning unsafe checks was certainly worthwhile.

I am talking about pruning evasions, not about pruning checks.

[bob]

I assume SF does not do checks at the 2nd q-search ply, although I have not looked. To do so is a wasted effort, since you are hoping that the check wins something, yet at the first q-search ply the opponent could always "stand pat.".

It does, but SF has very strict conditions for delivering checks in qsearch. Non-capturing checking moves are always pruned unless SEE >= 0 and one of the following conditions is fulfilled:
- Stand pat is very close to beta (<= 0.25cp)
- It's a double threat and capturing victim allows us to reach beta
- It's a queen contact check
- Opponent's king has at maximum one escape squares

Using this condition and delivering checks in two q-search plies was the optimal way for us. Not a biggie though, something around 5-10 ELOs. You might want to try something like this in Crafty.

I did, but it seemed to hurt very slightly. Cray Blitz had a 4-ply "zone" at the front of q-search where we included captures, checks, and a few special moves that appeared to contain a tactical threat. But if we did not search a checking move at the first ply, we would not consider checking moves at all at the 3rd, because of the stand-pat at the second that our opponent could use to avoid a forced mate where some moves are not checks.

In Crafty, I added the 1 course of checks so that I could test null move R=3 everywhere, rather than the adaptive R=2~3 based on depth remaining. And it was a _very_ slight gain overall to do this, I'm still not sure it is worth the cost of the code complexity.

The biggest gains I found were inside the normal search. For a check, if SEE < 0, not only don't I extend it, but I can reduce it...

[bob]

but pruning unsafe checks was certainly worthwhile.

I am talking about pruning evasions, not about pruning checks.

I understood. My comment still stands. Once you do a check, you are committed to doing extra work, namely trying all evasions except a few you might prune. If you avoid the check itself, all of that overhead goes away. And I found an actual gain in doing that. If you search all checks, then pruning SEE < 0 evasions might be where you see a gain, but since I was already excluding unsafe checks, excluding unsafe evasions didn't help me at all...

[bob]

I am not sure that the PV condition makes a lot of sense.

You're probably right! Generally speaking introducing such path dependant conditions is theoretically unsound when used with a htable. So all these pv conditions should be tested, and unless they actually prove usefull, they should be avoided.
I've found however that extending recaptures by 1/2 ply at non PV nodes and 1 ply at PV nodes performs a little (but significantly) better in practice. Probably because:
- on the one hand you have a PV condition which doesn't make sense in theory
- on the other hand extending all recaptures by 1 ply is far too costly and explodes the search tree
- so in the end the result is an overall positive.
I'll try to remove each pv condition and test to see if it is actually useful.

For the record, the _only_ extension I currently use is "getting out of check". I tested a ton of alternatives a couple or three years back, and each time came back to the same conclusion. Each costs more than it returns. Some were very marginal losses, some gave zero Elo. The only beneficial extension I found and kept was the getting ouf of check extension.

[mcostalba]

but since I was already excluding unsafe checks, excluding unsafe evasions didn't help me at all...

No, I don't think you have understood. For each check you can have multpile evasions at the next ply.

Say you are doing a safe check and at the child node you have 5 evasions to try. The idea is to try just a sub-set (say the first 2) and then discard the other 3.

This is the idea of Joona.

[lucasart]

I am not sure that the PV condition makes a lot of sense.

You're probably right! Generally speaking introducing such path dependant conditions is theoretically unsound when used with a htable. So all these pv conditions should be tested, and unless they actually prove usefull, they should be avoided.
I've found however that extending recaptures by 1/2 ply at non PV nodes and 1 ply at PV nodes performs a little (but significantly) better in practice. Probably because:
- on the one hand you have a PV condition which doesn't make sense in theory
- on the other hand extending all recaptures by 1 ply is far too costly and explodes the search tree
- so in the end the result is an overall positive.
I'll try to remove each pv condition and test to see if it is actually useful.

For the record, the _only_ extension I currently use is "getting out of check". I tested a ton of alternatives a couple or three years back, and each time came back to the same conclusion. Each costs more than it returns. Some were very marginal losses, some gave zero Elo. The only beneficial extension I found and kept was the getting ouf of check extension.

On the other hand I have not tested 1/2 ply extension of recaptures, regardless of the PV-ness of the node.
I'll go ahead and test that, although my testing method is currently the 300 wac positions, which is very biaised towards sacrificial attacks, and doesn't represent "average" chess game positions.

[Evert]

So I read my qsearch again and again, and I finally found the solution in StockFish. I was just pruning see < 0 without distinction,

I do that too.

So if my search exploded it's probably because of all the useless non capturing check evasions. Also I was brutally pruning see < 0 at PV nodes, which is dangerous (I was even pruning the tt move...)

I think I always prune moves with see<0 in the Q-search, but I don't do checking moves (mainly because I don't have an efficient generator for them). I used to have a separate transposition table for the Q-search (for two reasons: I didn't want to pollute the main table with inaccurate QS results, and I don't want to deal with non-captures in QS) but I got rid of it since I couldn't show that it did anything useful.

Just out curiosity I wonder who invented this SEE pruning refinement. Was it first seen in SF or were there previous open source program doing that ? Perhaps Crafty ?

I think I got the idea off the chess programming wiki, but it makes sense to try it if you think about it.

[lucasart]

For example I'd want it to play 100 games in 1'+1" against another uci engine, and see the score and the pgn.

Why don't use Cutechess-Cli tool for this task? It can do exactly this, and much more...

thanks!
the gui version is very buggy but once i have written the uci interfacing code (not started yet), i'll try the CLI version. it seems to be exactly what i have always been looking for (finally i won't need wine+arena!)

[hgm]

(finally i won't need wine+arena!)

You actually never needed that, because XBoard could already do this natively on Linux long before Arena was born...

[lucasart]

(finally i won't need wine+arena!)

You actually never needed that, because XBoard could already do this natively on Linux long before Arena was born...

but it can't do automated engine tournaments, or am i mistaken ?
that's really the only thing I want an uci interface to do. I dont even care about having a gui