Article : Tactical Quiescence Search (TQS)

[Paul JF]

I've wrote an article about something I call Tactical Quiescence Search (TQS).
Here is the link : https://github.com/PaulJeFi/pauljefi.gi ... cle/TQS.md
Actually this is a normal QS, used in most engines. I call it TQS because when I started writing my first chess engine, I used only capture moves in QS, like it is described in CPW, but it was not the most efficient. Nowhere in the CPW article about QS was mentioned other moves than capture-only, and when I discovered that many engines uses others non-quiet moves in QS, I didn't understand why CPW didn't talk about it. So I decided to write this article for new chess engine programmers.

[hgm]

I thought state of the art in strong engines is to search captures and promotions, all check evasion, and checking moves in the first two ply. Search checks at every depth often leads to search explosion, as these could go on forever.

[Ras]

Here is the link : https://github.com/PaulJeFi/pauljefi.gi ... cle/TQS.md

Two typos:
First example: Rd8# should be Rf8#.
Second example: Qa6+ should be Qa4+ (two times).

[Tearth]

I thought state of the art in strong engines is to search captures and promotions, all check evasion, and checking moves in the first two ply. Search checks at every depth often leads to search explosion, as these could go on forever.

It's funny because I can't count how many times I tried to introduce check evasions in QS (even very restricted, to avoid search explosion) and it was always no difference at best or just an Elo loss. Clearly, I'm doing something fundamentally wrong...

[algerbrex]

I thought state of the art in strong engines is to search captures and promotions, all check evasion, and checking moves in the first two ply. Search checks at every depth often leads to search explosion, as these could go on forever.

It's funny because I can't count how many times I tried to introduce check evasions in QS (even very restricted, to avoid search explosion) and it was always no difference at best or just an Elo loss. Clearly, I'm doing something fundamentally wrong...

I wonder, couldn't it just be that check extensions in the main search along with other factors (e.g. engine so greater depths reached/more nodes searched), just make it so that check evasions in qsearch don't add any benefit, or slow down the engine too much so that any tactical gain is offset?

I think often times these sort of optimizations can be very finicky and particular to each engine.

Sure if an author isn't able to get the big stuff working (e.g. transposition table, alpha-beta pruning, MMV-LVA, null-move search) then I agree they've gone fundamentally wrong somewhere as all of those techniques are tried and true and have been proven time and time again to be significant gains in strength.

But once you move past the bigger stuff towards smaller optimizations, I don't think one necessarily has to worry as much if they can never quite get it work with their engine. Absolutely it's frustrating, as you feel like there's potential strength your engine is missing out on, but rationally it could just be about the particulars of one's engine.

For Blunder, for whatever reason, I've never gotten delta-pruning to work, it's always an Elo loss or no gain. And I've tried several different variations, some involving SEE, some using a constant margin, some using SEE, and a constant margin, etc. But nothing has worked, and I'm starting to suspect it's simply because of many little peculiarities in Blunder.

Now of course this could also be because of slightly mis-tuned parameters and margins elsewhere in the search, but at that point too, I question whether it's worth the effort to try to sus the necessary changes out, given how there's no easy way to deal with reliably tuning orthogonal search parameters. At least compared to focusing your efforts elsewhere first.

[Paul JF]

Thank you so much for all these answers.

I thought state of the art in strong engines is to search captures and promotions, all check evasion, and checking moves in the first two ply. Search checks at every depth often leads to search explosion, as these could go on forever.

I think you are right, actually I am in the amazing chess programming wold for only one year, so I am quite new and "unexperienced".

Two typos:
First example: Rd8# should be Rf8#.
Second example: Qa6+ should be Qa4+ (two times).

Thank you, I will fix this.

It's funny because I can't count how many times I tried to introduce check evasions in QS (even very restricted, to avoid search explosion) and it was always no difference at best or just an Elo loss. Clearly, I'm doing something fundamentally wrong...

As algerbrex said it, some "improvement" in an engine could be worse (or bad) in another one. I use TQS in my first engine, Ramsès-Chess, and it was an improvement on its playing strength, because of its fixed (and importantly about TQS, low) search depth (3 or 4) on its Lichess account. So at low depth, TQS is critical to not lose importants tactics, but I suspect TQS to slow down particularly the search at hight depth.

[algerbrex]

I wonder, couldn't it just be that check extensions in the main search along with other factors (e.g. faster engine so greater depths reached/more nodes searched), just make it so that check evasions in qsearch don't add any benefit, or slow down the engine too much so that any tactical gain is offset?

Typo correction in bold.

[Bo Persson]

As algerbrex said it, some "improvement" in an engine could be worse (or bad) in another one.

The order you add the improvements is also important to their perceived effect. The first couple of tricks will have lots of low hanging fruit to pick.

However. the 23rd search extension might not help much, if at all, as the potentially bad moves have already been weeded out.

[dangi12012]

However. the 23rd search extension might not help much, if at all, as the potentially bad moves have already been weeded out.

Yes yes - and then you need to go through the permutations of all improvements since each on its own might improve elo - but together they break some optimisations or cause search explosions and whatnot.

But I think there are some curated lists out there of all known extensions in the CPW and elsewhere.
Just use a bit for one optimisation and increment it and recompile. If you have 6 new extensions you can build 64 engines and you can have a perfect tournament crosstable to see where the optimum is. But I would keep it at 4 added extensions at a time to have a tournament with 16 engines.

Code: Select all

int alphabeta(...)
{
	if constexpr (extensionflags & 0b0010)
	{
	  //Do extensions here
	}
}