ymatioun wrote:I just searched this position with Fizbo to depth 39/seldepth 67, and it still does not see a draw.
It looks to me that the depth for a forced repetition draw here s really very high (black king can go on most squares in files f-g-h twice before it happens).
I don't have any special logic to recognize perpetual check, so i would not expect Fizbo to see it.
Does anybody use special logic for these positions?
Thanks.
I use two kind of test:
- I store the already played positions of the game in the hash, with a flag TT_DRAW; when I find one of those positions during search, I return 0 (or a little less)
- I check actual position hash with the one of two plyes before; this signal forth/back couple of moves
I still miss repetition of multiple moves in the search.
Andscacs sees 0 at depth 12 with seldepth 36, the same maximum theorical depth that Karlo Bala told, but I doubt is related to this limit.
I have not implemented any special rule to detect such positions. Is consequence simply of the normal search, which detects repetitions as draw. It prunes/reduces as always, and in the lines that it searches it does not find a way for the black king to scape the checks.
So if a position had some strange resource to scape the perpetual, maybe Andscacs will not see it and will think that is 0 while maybe it was lost. As always is a statistical tradeoff when deciding what goes inside the engine.
zenpawn wrote:Regarding check extensions, it basically accomplishes the same goal to include checks in qsearch, right?
Only partially. "Same goal" by improving tactical abilities, but that's a very general goal.
Check extension means that you extend replies to check slightly deeper, e.g. one ply. This can help to find forced variations that start with giving check.
Including checks in qsearch is a bit different, here you make the search wider by adding more moves to be searched (quiet checks), but you only do that during the first N plies of qsearch, typically N=1. This will basically extend the horizon at some leaf nodes. But the kind of extension is not the same as for check extension.
Sven Schüle wrote:
Including checks in qsearch is a bit different, here you make the search wider by adding more moves to be searched (quiet checks), but you only do that during the first N plies of qsearch, typically N=1. This will basically extend the horizon at some leaf nodes. But the kind of extension is not the same as for check extension.
Wider versus a qsearch without checks, sure, but if you don't limit checks to the first N-ply, then I don't see how it's not doing the same thing as check extensions.
Check extension would cause a brach that starts with a check in the root to be searched deeper than the other branches, even in the d=10 iteration. Searching checks in QS would not treat lines that started with a check any different from those that didn't. Only lines that have a check as the 11th ply.
Sven Schüle wrote:
Including checks in qsearch is a bit different, here you make the search wider by adding more moves to be searched (quiet checks), but you only do that during the first N plies of qsearch, typically N=1. This will basically extend the horizon at some leaf nodes. But the kind of extension is not the same as for check extension.
Wider versus a qsearch without checks, sure, but if you don't limit checks to the first N-ply, then I don't see how it's not doing the same thing as check extensions.
In theory you would almost be right but that won't work in practice since it would result in an unmanageable tree explosion. It would search a much larger tree than with just check extension. The latter does not add checks and their subtrees, it just extends replies to checks which were already there.
Consider this example of a queens ending which could be reached one ply above the horizon of a full-width search:
[d]2q5/p5k1/1p1Q4/1Pp5/P1P5/8/4K3/8 w - - 0 1
The last ply of full-width search will probably include to search checks like 1.Qe5+ or 1.Qg3+. Check extension will ensure to search all check evasions for these instead of doing an immediate qsearch (which can be misleading when in check). After these replies you would start a regular qsearch, and there will be only very few captures to consider. However, adding checks in qsearch will change a lot here. White to move will have many more checks (which get check-extended as well), and you will see a heavy tree explosion if you do not limit checks in qsearch to some N. The white queen will try to give check where it can.
I am not sure this is a good thing though. It probably means that texel is doing too many extensions which likely hurts more than it helps on average. Texel uses both check extensions and singular extensions.
