ChessGUI 0.245h

[Matthias Gemuh]

I tried to set it at 1s/pos, with fast mode enabled and correct plys set to 2.
It is still 2/82. Stopped it for now.
In arena I got 75/75.

No surprise if Deuterium depends on "isready" to setup a position and analyze it.

[Matthias Gemuh]

Hello Matthias,

It does seem as if Deuterium has an issue in this mode. It scored 0 after about 20 of the problems. The Baron seems quite happily solving up to position 183 here...

Later.

Hi Roger,
only a few UCI engines have the issues. I will eventually give them their "isready" for the sake of peace.

[Matthias Gemuh]

Thanks for taking the time to work on ChessGUI some more.

Your efforts are appreciated and you should feel proud of what you've achieved so far with ChessGUI.

There will always be little issues with any GUI, but you shouldn't let that discourage you.

Graham.

Hi Graham,

some of those ICC games did not even have moves.
I hope book creation now works as intended.

Matthias.

[Ferdy]

I tried to set it at 1s/pos, with fast mode enabled and correct plys set to 2.
It is still 2/82. Stopped it for now.
In arena I got 75/75.

No surprise if Deuterium depends on "isready" to setup a position and analyze it.

The isready is not necessary for Deuterium, but ucinewgame. This ucinewgame command is what it needs when it is not playing a game.
But even if the gui does not send the ucinewgame command,
Deuterium would adjust by examining the history of the moves, if there is
then it will try to parse the move history, then it will compare with the current position given. If the current position could not be found then it
will reset its history, setup the board based on the fen and initialize other things, after which it is
now ready to process the next command.

[Matthias Gemuh]

I tried to set it at 1s/pos, with fast mode enabled and correct plys set to 2.
It is still 2/82. Stopped it for now.
In arena I got 75/75.

No surprise if Deuterium depends on "isready" to setup a position and analyze it.

The isready is not necessary for Deuterium, but ucinewgame. This ucinewgame command is what it needs when it is not playing a game.
But even if the gui does not send the ucinewgame command,
Deuterium would adjust by examining the history of the moves, if there is
then it will try to parse the move history, then it will compare with the current position given. If the current position could not be found then it
will reset its history, setup the board based on the fen and initialize other things, after which it is
now ready to process the next command.

I will analyze the issue and fix it in ChessGUI.

[Ferdy]

I checked the ChessGUI output table and also enable and check Deuterium log. This is from current dev version.

The story.
Deuterium receive the position and go commands, later the stop command from ChessGUI.
After receiving the stop command, Deuterium sent the bestmove, this is pos 1 and Deuterium received 1 point. Then ChessGUI sent again the stop command, so Deuterium said,
From Deuterium log.

Code: Select all

string received: stop 
>> stop 
Deuterium is no longer searching, and bestmove was already sent 
<< bestmove 0000

Deuterium sent 0000 as bestmove to ChessGUI. Now this move is found in the output table in pos 2. ChessGUI determined that 0000 is the bestmove for pos 2.
This is where the problem started. They are now out of sync.

Here is the output table.

Code: Select all

Deuterium v2015.1.35.237
C:\Chess\Test suite\epd_testsuites\wacnew.epd
   Nr   Result          Score       Pts        Move      Time        TimeSum        Elapsed           Eval ShortPV                                                                                                                          FEN
       1     1          1 / 1         0         Qg6     0.062          0.062          5.000      Mate in 2   g3g6 f7g6         2rr3k/pp3pp1/1nnqbN1p/3pN3/2pP4/2P3Q1/PPB4P/R4RK1 w - - bm Qg6;                                                                    g3g6 f7g6 e5g6 
       2     0          1 / 2         0        0000     5.000          5.062         10.000            0.0   g3g6 f7g6         8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - - bm Rxb2;                                                                                g3g6 f7g6 e5g6 
       3     0          1 / 3         0        b3b2     5.000         10.062         15.000           5.27   b3b2 d2b2         5rk1/1ppb3p/p1pb4/6q1/3P1p1r/2P1R2P/PP1BQ1P1/5RKN w - - bm Rg3;                                                                    b3b2 d2b2 c4c3 b2b6 f6e7 b6c6 c3c2 f3f2 e7d7 c6c3 d3d2 c3c2 d2d1q c2c5 d7d6 c5e5 d1h1 f2g3 h1g1 g3f3 g1h2 e5a5 h2c2 a5a6 d6c5 a 
       4     0          1 / 4         0        e3g3     5.945         16.007         20.000           3.67   e3g3 d7g4         r1bq2rk/pp3pbp/2p1p1pQ/7P/3P4/2PB1N2/PP3PPR/2KR4 w - - bm Qxh7;                                                                    e3g3 d7g4 g3g4 h4g4 e2g4 g5g4 h3g4 c6c5 f1e1 c5d4 c3d4 f8d8 e1e4 d6c5 d2c3 c5d6 h1f2 d8d7 f2d3 d7g7 c3d2 g7g4 d3e5 g4h4 
       5     0          1 / 5         0        h6h7     6.470         22.477         25.000      Mate in 2   h6h7 h8h7         5k2/6pp/p1qN4/1p1p4/3P4/2PKP2Q/PP3r2/3R4 b - - bm Qc4;                                                                             h6h7 h8h7 h5g6 

Deuterium log.

Code: Select all

string received: ucinewgame
>> ucinewgame
string received: isready
>> isready
<< readyok
string received&#58; position fen 2rr3k/pp3pp1/1nnqbN1p/3pN3/2pP4/2P3Q1/PPB4P/R4RK1 w - - 0 1
>> position fen 2rr3k/pp3pp1/1nnqbN1p/3pN3/2pP4/2P3Q1/PPB4P/R4RK1 w - - 0 1
This is a new game
There is fen, board is initialized
string received&#58; go infinite
>> go infinite
Set infinite search to true
string received&#58; stop
>> stop
Make the legal move in internal board
We are in infinite mode and we receive a stop command
<< bestmove g3g6
Takeback the last move in internal board
<<<<<<
string received&#58; stop
>> stop
Deuterium is no longer searching, and bestmove was already sent
<< bestmove 0000
string received&#58; position fen 8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - - 0 1
>> position fen 8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - - 0 1
This is not a new game
Reset to new game, there is no move
There is fen, board is initialized
string received&#58; go infinite
>> go infinite
Set infinite search to true
string received&#58; stop
>> stop
Make the legal move in internal board
We are in infinite mode and we receive a stop command
<< bestmove b3b2
Takeback the last move in internal board
<<<<<<

[Graham Banks]

Thanks for taking the time to work on ChessGUI some more.

Your efforts are appreciated and you should feel proud of what you've achieved so far with ChessGUI.

There will always be little issues with any GUI, but you shouldn't let that discourage you.

Graham.

Hi Graham,

some of those ICC games did not even have moves.
I hope book creation now works as intended.

Matthias.

I will try it out and let you know how I get on.

[Roger Brown]

Thanks for taking the time to work on ChessGUI some more.

Your efforts are appreciated and you should feel proud of what you've achieved so far with ChessGUI.

There will always be little issues with any GUI, but you shouldn't let that discourage you.

Graham.

Hello Graham,

I second this.

Even more though is that the fact there are a number of guis provided for free that transparently support UCI and Winboard protocol engines, do everything that I could want in a gui ( and more if you think about the non-traditional chess -like games supported by Winboard) and are written by authors who implement features and requests, not to mention bug-fixes.

It is astonishing and certainly an example for some commercial guis to follow...

Thanks Matthias.

Later.

[Matthias Gemuh]

I checked the ChessGUI output table and also enable and check Deuterium log. This is from current dev version.

The story.
Deuterium receive the position and go commands, later the stop command from ChessGUI.
After receiving the stop command, Deuterium sent the bestmove, this is pos 1 and Deuterium received 1 point. Then ChessGUI sent again the stop command, so Deuterium said,
From Deuterium log.

Code: Select all

string received: stop 
>> stop 
Deuterium is no longer searching, and bestmove was already sent 
<< bestmove 0000

Deuterium sent 0000 as bestmove to ChessGUI. Now this move is found in the output table in pos 2. ChessGUI determined that 0000 is the bestmove for pos 2.
This is where the problem started. They are now out of sync.

Thanks, Ferdinand.
I am investigating the issue also, not just what happens with bestmove.
This your input is definitely helpful.

[hgm]

Code: Select all

<< bestmove g3g6
Takeback the last move in internal board
<<<<<<
string received&#58; stop
>> stop
Deuterium is no longer searching, and bestmove was already sent
<< bestmove 0000

This is a bad violation of UCI protocol. An engine should NEVER produce more than one 'bestmove' command in response to a 'go' command. (And also never fewer than one, btw.)

This is the main reason for the phrase in the UCI specs that engines should IGNORE commands that are not supposed to come when they come. Such as 'stop' when the engine is not searching.

There is a race condition in timed 'go' commands that makes it impossible to know whether a 'stop' sent by the GUI because of a 'move now' event has crossed the 'bestmove' sent by the engine because the search timed out. 'Bestmove' is NOT a reply to 'stop'; it is a (mandatory) reply to 'go' on which all GUI-engine synchronization is based.