Winboard Forum

Hi folks,
this position was posted in the WBEC-Ridderkerk forum by AICE author Anastasios Milikas:

[diag]8/1QB3k1/1P2p3/1P2PqP1/6K1/5P2/8/8 w - - 0 66[/diag]

There is a draw by perpetual check here, and I tested several engines on it. Yace returns a draw score almost immediately (depth 10), Delfi 4.5 takes just a little more (depth 14) and Crafty 19.15 takes still more time (depth 18).

It goes without saying that Kiwi doesn't see it at all!

What do you think... is it better to add some specific code that gets suspicious when there are too many consecutive checks, or by simply (!) improving the search one will eventually get a draw by repetition?

please give the FEN.

regards Joachim

Hi, if you quote his post, you'll see the FEN

Joachim Rang wrote:please give the FEN.

regards Joachim

Ops sorry, I didn't notice the "diag" command doesn't echo the FEN, here it is:

8/1QB3k1/1P2p3/1P2PqP1/6K1/5P2/8/8 w - - 0 66

I have some 'draw suspicion' code in SpiderChess and in this case it works. The engine immediately returns the appropriate near draw score (+0.10 for white in this case).
But recently SC couldn't win a clearly won Q-ending in the ChessWar tournament and I suspect that the draw code was to blame for that. The engine evidently tried to avoid draws that weren't there for a long time until it finally blundered. It exchanged queens and saw too late that the resulting pawn endgame was .. drawn.

So, maybe I should remove this code. Or try to tune it better.
It's as subtle as a chainsaw at the moment.

Hi all!
It was funny that AICE resigned in a draw position but this helped me to track the bug (if it is a bug). The solution I found is to extend checks BEFORE probing hashtable or going in QS. This helped much. Now it finds the draw in depth 13 in about 30 secs on my Athlon XP 1600+. But this is still slow. Fritz8 finds it in seconds. And for bug-tracking purposes also try the following position (one move before):
8/1QB3k1/1P2p1q1/1P2P1P1/6K1/5P2/8/8 b - - 0 65
[diag]8/1QB3k1/1P2p1q1/1P2P1P1/6K1/5P2/8/8 b - - 0 65[/diag]

The draw must not be found earlier! (extending checks in root search).

Anastasios Milikas

Yace uses "several checks in a row extensions" (expecially for the "defender" with less material). But I am starting to doubt, how well this works. It costs depth ...

Regards,
Dieter

When I tried this position with the engine I am working on (names Ceng tentatively ) , it could not see the draw for reasonable depth/time.
Though a simple change ensures that it does see it very fast - allowing draw score's to be stored in transposition table.
This seems to be a combination I need to look into more since I try to "agressively" hash singular extensions.
Thanks for the pos - never thought of looking into similar problems until now for this new baby