Engines losing on time in won/drew games

[Carlos777]

Another annoying problem on Arena:

Both sides having only one rook and both showing scores 0.000,
they continue playing up to mate!

Same applies to RvN, RvB, RBvR and similar endgames.

Its pity that Arena does not have a draw score adjudication
feature for such cases.

Best,

Yes, adjudication on those cases would be nice too.

[hgm]

The thing about the Autoflag set to off is that is not fair for the other engines that do comply with the TC.

What is even worse, is that when an engine crashes, the game will last forever with autoFlag off, and bring the tiourney to a halt.

In WinBoard the option -trivialDraws will adjudicate end-games like KRKR, KBKB and KNKN. It could be extended to KRKB and KRKN, but that is a bit tricky without consulting tablebases to see if it is really draw. Adjudicating on an engine draw score does not work. The whole problem arises because one of the engines thinks it is ahead, and avoids repetition. In my experience, even with the trivial-draw adjudication off, end-games like KRKR very quickly run into a 3-fold rep.

[beachknight]

Another annoying problem on Arena:

Both sides having only one rook and both showing scores 0.000,
they continue playing up to mate!

Same applies to RvN, RvB, RBvR and similar endgames.

Its pity that Arena does not have a draw score adjudication
feature for such cases.

Best,

Yes, adjudication on those cases would be nice too.

Another problem of Arena is :

I like all the detailed variants which other GUIs like CBs or
WB does not have. But ECO Codes are frequently wrong.
I really hate this.

Every time I must correct them all. You know thousands of games...

CB GUIs show the correct ones almost always.

Best,

[beachknight]

The thing about the Autoflag set to off is that is not fair for the other engines that do comply with the TC.

What is even worse, is that when an engine crashes, the game will last forever with autoFlag off, and bring the tiourney to a halt.

In WinBoard the option -trivialDraws will adjudicate end-games like KRKR, KBKB and KNKN. It could be extended to KRKB and KRKN, but that is a bit tricky without consulting tablebases to see if it is really draw. Adjudicating on an engine draw score does not work. The whole problem arises because one of the engines thinks it is ahead, and avoids repetition. In my experience, even with the trivial-draw adjudication off, end-games like KRKR very quickly run into a 3-fold rep.

More endgames coming speedily into mind:

KQKRP
KRKNP
KRKBP
KQPKRR

What I meant with draw score adj. was :
The GUI could be able to adj. the game as draw
when both engines showing 0.000 or +/- 0.3000
for twenty moves.

Best,

[hgm]

Well, I wonder how useful the latter is. In my experience, if the both show 0.00, they won't last 20 moves, but will draw by repetition within 10.

And the problem is that they score KQKRP as +3.50, not as 0.00. These are difficult end-games, though, that most engines would not know how to evaluate. So asking it from a GUI is a bit much.

I have been thinking about adding bitbase adjudication, though. One possible way to do this would be to allow the user to tick check boxes for the end-games where he would want to adjudicate draw in positions that are draws, and (independently) where he wants the wins adjudicated too.

[beachknight]

Well, I wonder how useful the latter is. In my experience, if the both show 0.00, they won't last 20 moves, but will draw by repetition within 10.

And the problem is that they score KQKRP as +3.50, not as 0.00. These are difficult end-games, though, that most engines would not know how to evaluate. So asking it from a GUI is a bit much.

I have been thinking about adding bitbase adjudication, though. One possible way to do this would be to allow the user to tick check boxes for the end-games where he would want to adjudicate draw in positions that are draws, and (independently) where he wants the wins adjudicated too.

Well, I might conduct all my tests with WB then

Lets see what rival GUIs offer.

Best,

[Carlos777]

The thing about the Autoflag set to off is that is not fair for the other engines that do comply with the TC.

What is even worse, is that when an engine crashes, the game will last forever with autoFlag off, and bring the tiourney to a halt.

That is a good point!

In WinBoard the option -trivialDraws will adjudicate end-games like KRKR, KBKB and KNKN. It could be extended to KRKB and KRKN, but that is a bit tricky without consulting tablebases to see if it is really draw. Adjudicating on an engine draw score does not work. The whole problem arises because one of the engines thinks it is ahead, and avoids repetition. In my experience, even with the trivial-draw adjudication off, end-games like KRKR very quickly run into a 3-fold rep.

Yes, some KRKB and KRKN are not draws and that would be determined by EGTBs like CB GUI does. The GUI checks if the endgame is a draw and adjudicate the game after both engines show +0.00 eval score for 3 times.

I'd also use Winboard if there is a more flexible WB tournament manager. Especially, if it permits adding, removing or replacing engines during the tournament as Arena does without having to restart the whole tournament. I used WB + Galis WBTM in the past, it was a good combo, but Arena is more flexible in these cases. It would be nice if configuring UCI engines were easier too.

Edit: About KRKR games, what would happen in the following position:

[D] 8/8/R6p/8/7k/4K3/8/7r w - -

After white plays Rxh6+, it is a won position for white, but it will be a KRKR endgame and if there were not EGTBs used for adjudicating the game, the gui would adjudicate it as a draw.

[hgm]

I thought PSWBTM did allow such replacement. I must admit I don't know how it works, because I never do it. (My tournaments are mostly fixed gauntlets for new versions of my engines.) But Olivier does it in Open War all the time, using PSWBTM.

What is wrong with the current way of configuring the UCI engines? (Setting the parameters through the WinBoard engine-settings dialog, and pressing the Polyglot Save button, possibly after launching WB from the engine manager of PSWBTM).

In WinBoard I adjudicate the trivial draws only after 3 full moves. (For KBKN and such that could actually be 1 move, but I never cared enough about those two extra moves to make the number of moves dependent on the material.)

[Carlos777]

I thought PSWBTM did allow such replacement. I must admit I don't know how it works, because I never do it. (My tournaments are mostly fixed gauntlets for new versions of my engines.) But Olivier does it in Open War all the time, using PSWBTM.

What is wrong with the current way of configuring the UCI engines? (Setting the parameters through the WinBoard engine-settings dialog, and pressing the Polyglot Save button, possibly after launching WB from the engine manager of PSWBTM).

In WinBoard I adjudicate the trivial draws only after 3 full moves. (For KBKN and such that could actually be 1 move, but I never cared enough about those two extra moves to make the number of moves dependent on the material.)

I also must admit that I did not try WB+PSWBTM recently.
I thought that it was not possible. I will try it and see what happens.

[Aaron Becker]

Having taken a closer look at the debugging output you posted, I'm a little confused about what's actually happening. Looking at just daydreamer's last 2 moves, here are the move commands and its final output for each:

Code: Select all

7.169.454-->1:go wtime 9511 btime 1871 winc 1000 binc 1000 
7.170.314<--1&#58;info depth 15 time 170 nodes 57823 score cp 0 pv b4b5 d4c3 c4c5 d6c5 b5c5 c3d3 c5b4 d3c2 b4a4 c2b1 a4b4 b1a1 b4a4 a1b1 
7.170.345<--1&#58;bestmove b4b5 

7.175.017-->2&#58;go wtime 9724 btime 487 winc 1000 binc 1000 
7.177.486<--2&#58;info multipv 1 depth 81 seldepth 0 score cp 0 time 376 nodes 10 nps 0 hashfull 0 tbhits 633 pv e4d4 
7.177.486-->2&#58;stop 
7.178.001*moveerror*black moved but it is white's turn !Ke4-d4! 

I read the number that starts each line as a millisecond timer. Black starts the first move with 1871ms on its clock at time 7.169.454, and produces a move at 7.170.345, 891ms later. By my count it should have 980+1000 = 1980ms on its clock to start the next move.

However, it actually starts the next move with 487ms on the clock. If we had positive time left on the clock after the last move, and the GUI added our increment of 1000ms, it should be impossible to start this move with only 487ms. Then daydreamer outputs an info line at time 7.177.486 (2469ms later), but it reports its time consumed as only 376ms.

Maybe I'm misreading the output, and the first number isn't actually a timestamp. But in any case, I don't understand how daydreamer started the last move with under 1000ms on the clock. I also have a hard time figuring out why daydreamer and the gui disagree by over 2s on the time of its info line in the second move. Maybe some disagreement can be explained by errors in my timing code, but an error of 2s on a reported time of 376ms is hard for me to figure out.

Does anyone have some suggestions for understanding this situation? I'd like to get this problem fixed, but it seems like there may be some underlying issue that I don't understand yet.