Stockfish SEE (and in general SEE related question)

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Stockfish SEE (and in general SEE related question)

Post by bob »

mcostalba wrote:
gladius wrote: Ah, so many ideas, so little time.
Yes, I know VERY well what you mean :-)

Here is my opinion (just an opinion).

The role of qsearch is NOT to find the best position or the best move.

Looking at the diagram you posted you said here in qsearch the engine discard BXN capture, and this looks strange.

But why looks strange?

Looks strange because when we, as humans, look at a diagram we always look at it (also if not conscious) from a PV point of view, i.e. we try to find the best move or the best confutation given a chess diagram. This human bias toward thinking always in term of principal variation can lead to misleadings when applied to chess engines.

If you do a little statistic you will see that 99% of qsearch calls are made from side branches, not from PV. And the logic from side branches is completely different and far from how humans look at a diagram.

The logic is that of the confutation. The job of side branches is _only_ to find a possible confutation to an _already exsistent_ PV and find it _as fast as it can_. The goal of search is NOT to find the best move, but to QUICKLY demonstrate that the already found best move (found by PV search) is actually not the real best move.

qsearch has much more to do with side branches then with PV and to understand an algorithm used in qsearch it is useful (for me it is) to start to look at it from the point of view of a side branch, not of a PV node.

So filtering out BXN is of course faster then considering it so that at the end you have a qsearch that discards BXN but is faster or a qsearch that includes BXN but is a bit slower: testing seems to show that speed is more important in this case. And my guess is that is more important _only_ because we are talking about side branches most of the time.
If you want to go even faster, why not filter out _all_ even exchanges? NxN, NxB, QxQ, etc. I used to do that in Cray Blitz, _after_ the first 4 plies of q-search, so that beyond 4 plies we only looked at captures that SEE said won material. I tried that in Crafty and it was weaker than trying all equal/winning captures at every ply in the q-search.
mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 9:17 pm

Re: Stockfish SEE (and in general SEE related question)

Post by mcostalba »

bob wrote: If you want to go even faster, why not filter out _all_ even exchanges? NxN, NxB, QxQ, etc. I used to do that in Cray Blitz, _after_ the first 4 plies of q-search, so that beyond 4 plies we only looked at captures that SEE said won material. I tried that in Crafty and it was weaker than trying all equal/winning captures at every ply in the q-search.
I was exactly thinking to this ! :D

And just to add something new I was also thinking to prune all the captures to the same square after the first.

Because captures are LVA ordered it means that if I capture on a given square with a pawn and that doesn't work, if on the same square I can attack also with a knight there is a good possibility that that will not work either, so I filter all the capture after the first (the LVA one) with destination a given square.

What do you think ? Also this was in Cray Blitz ? :lol:
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Stockfish SEE (and in general SEE related question)

Post by bob »

mcostalba wrote:
bob wrote: If you want to go even faster, why not filter out _all_ even exchanges? NxN, NxB, QxQ, etc. I used to do that in Cray Blitz, _after_ the first 4 plies of q-search, so that beyond 4 plies we only looked at captures that SEE said won material. I tried that in Crafty and it was weaker than trying all equal/winning captures at every ply in the q-search.
I was exactly thinking to this ! :D

And just to add something new I was also thinking to prune all the captures to the same square after the first.

Because captures are LVA ordered it means that if I capture on a given square with a pawn and that doesn't work, if on the same square I can attack also with a knight there is a good possibility that that will not work either, so I filter all the capture after the first (the LVA one) with destination a given square.

What do you think ? Also this was in Cray Blitz ? :lol:
Did not try that, so have no idea. My thinking in Cray Blitz, where depths were far lower than today, was that the q-search is really about eliminating tactical threats before getting to the static evaluation code. Early even exchanges do find some stuff, like BxN, PxB, RxP because the knight was the only defender of that pawn. But after 3-4 plies, you have so many errors in the q-search already, since in most cases the best move is never a capture anyway, that I wanted to get out of the search as quickly as possible to speed things up.

And as you might guess, when I decided to do Crafty, I duplicated almost every algorithm that was in Cray Blitz unless it was simply too expensive (our CB mobility was quite good, but depended on vector hardware for example). But I eventually found, via testing, that the q-search was better off left alone. I did prove to myself that ignoring losing captures is safe enough, as there is little good in QxN if the knight is defended. But as I said, most of this is really minor in terms of Elo, even if it does sound quite reasonable in theory.

the 3-4-5 (I do not remember exactly what now) improvement when I changed the B=N in Swap() code was not really a surprise. I found this when I was eliminating all the black/white duplication of code from Crafty 21.x, when I moved to 22.0, and I noticed that in Swap() I was using the one with the traditional piece values (B=325, etc) rather than the simple B=N=300 and such array. That was never intended, but it also was not so obvious until I did the conversion. When I fixed it, it was better, which is where I left it.