FRC in CECP

[lucasart]

I had a look at the documentation, but I'm still confused http://hgm.nubati.net/CECP.html.
* engine declares support by having "fischerandom" in the variants feature.
* but gui sends instead "variant fairy".
* gui should use "a shuffle request in the setup FEN": what does that mean ? is it a fancy way of saying that gui sends an FRC position (in FEN format) ? i don't understand the "shuffle request" part.
* which FEN format should be used ? Normal (X-FEN) or S-FEN ?

[hgm]

I had a look at the documentation, but I'm still confused http://hgm.nubati.net/CECP.html.
* engine declares support by having "fischerandom" in the variants feature.

Correct.

* but gui sends instead "variant fairy".

No. It should send 'variant fischerandom'. Variant 'fairy' should only be send when the user selects 'fairy' from the New Variant menu dialog.

* gui should use "a shuffle request in the setup FEN": what does that mean ? is it a fancy way of saying that gui sends an FRC position (in FEN format) ? i don't understand the "shuffle request" part.

This is not relevant for FRC, which is a 'standard variant' in CECP, of which the GUI is supposed to know the rules, and in particular that these involve shuffling. This whole business with 'setup FENs' only applies to 'engine-defined variants', i.e. variants the GUI has never heard of, and has no clue as to what the rules are. The engine must then configure the GUI for the applicable rules. An important part of the rules is the initial position, and the engine sends that to the GUI as a FEN in a 'setup' command.

* which FEN format should be used ? Normal (X-FEN) or S-FEN ?

The CECP specs specify the engine (or GUI) should be able to understand both. WinBoard sends Shredder FEN.

[lucasart]

I had a look at the documentation, but I'm still confused http://hgm.nubati.net/CECP.html.
* engine declares support by having "fischerandom" in the variants feature.

Correct.

* but gui sends instead "variant fairy".

No. It should send 'variant fischerandom'. Variant 'fairy' should only be send when the user selects 'fairy' from the New Variant menu dialog.

* gui should use "a shuffle request in the setup FEN": what does that mean ? is it a fancy way of saying that gui sends an FRC position (in FEN format) ? i don't understand the "shuffle request" part.

This is not relevant for FRC, which is a 'standard variant' in CECP, of which the GUI is supposed to know the rules, and in particular that these involve shuffling. This whole business with 'setup FENs' only applies to 'engine-defined variants', i.e. variants the GUI has never heard of, and has no clue as to what the rules are. The engine must then configure the GUI for the applicable rules. An important part of the rules is the initial position, and the engine sends that to the GUI as a FEN in a 'setup' command.

* which FEN format should be used ? Normal (X-FEN) or S-FEN ?

The CECP specs specify the engine (or GUI) should be able to understand both. WinBoard sends Shredder FEN.

Thanks. So FRC is actually easier than in UCI, as there is no need to carry around a Chess960 state in both the Engine and the GUI to know whether to use e1h1 or e1g1, because we just use O-O notation.

On the subject of CECP, as I'm experimenting with it in c-chess-cli, I have some questions on the "modes":

• Why do we need WHITE and BLACK modes ? On the engine side, the only mode I need is FORCE, because I need to know if I'm parsing raw moves (FORCE), or CECP commands (NORMAL).
• When the engine is in FORCE mode, how does it know to go back to NORMAL mode ? By receiving a go command ?

[lucasart]

When the engine is in FORCE mode, how does it know to go back to NORMAL mode ? By receiving a go command ?

For me the logic would dictate that a parser with modes should be written like that:

Code: Select all

if (mode == NORMAL) {
    // parse any command
    // in particular the "force" command sets mode = FORCE
} else if (mode == FORCE) {
    // parse moves only
    // how do we escape from this state now ?
}

But that's impossible, because we can't escape the mode = FORCE state. Unless we turn the whole thing into a linear mess, where we parse it all, commands and moves combined (checking the first token to see if it looks like a move), which defeats the purpose of having mode in the first place...

There should be a separate command, which is *only* parsed when mode = FORCE, to say "exit forced mode, go back to NORMAL".

Or better yet, the UCI way, where the whole "position fen ... moves ..." is self-contained, and no state is required.

[jdart]

Why do we need WHITE and BLACK modes ? On the engine side, the only mode I need is FORCE, because I need to know if I'm parsing raw moves (FORCE), or CECP commands (NORMAL).
When the engine is in FORCE mode, how does it know to go back to NORMAL mode ? By receiving a go command ?

Note that the "white" and "black" commands are now deprecated.

I exit force mode in several circumstances: a "go" command, a "new" command, or end of game commands such as "result," which trigger the same processing as an explicit "new".

CECP is hard. I have fixed bugs in my implementation even recently, and I've supported it in my engine for 25 years or so.

[lucasart]

I exit force mode in several circumstances: a "go" command, a "new" command, or end of game commands such as "result," which trigger the same processing as an explicit "new".

Thanks. But that means there is no clean solution ? You have to duplicate handling code for all possible escape commands, one copy in forced mode, another in normal mode.

In fact there are much more command that have to be parsed in force mode. Any go parameter such as st, sd, otim, time, …; because they will arrive between setboard+force and go.

[hgm]

It is conceptually wrong/counterproductive to consider 'force mode' a different mode of the protocol. It is one of the internal states of the engine (in addition to the game state and the ponder mode; let's call it 'player state'). This machine state can take on the values WHITE, BLACK, FORCE or ANALYZE. In 'force mode' you can receive exactly the same set of commands as in WHITE or BLACK mode. In particular, you can receive moves in all of the modes. In CECP each move is a separate command. There is also no different set of commands in ponder on or ponder off mode, or depending on whether white or black is to move. (There is a restriction on the commands you can send in ANALYZE mode, though, but this doesn't really exclude anything it would make sense to send.)

This introduction of the 'usermove' command in v2 of the protocol makes this more obvious. It also removes the parsing problem you mentioned: with the 'usermove' command you never have to guess whether an input token will be a move or a command; the first token on any line will always be the command keyword, and moves can only occur as an argument to the 'usermove' command. The engine must be able to process this command in all of the 4 modes. For backward-compatibility reasons the use of the 'usermove' command by the GUI must be switched on through 'feature usermove=1', just like the use of 'setboard' for loading positions has to be requested explicitly.

The difference between the modes WHITE and BLACK is pretty essential: it determines whether the engine will automatically start thinking when the turn of that player comes up in the game state. No commands are required (or exist) to directly order the engine to search. What the commands do is set the player state of the engine (or alter the game state, or both). This player state, together with the game state and ponder mode then determine what the engine is going to do at any time (i.e. which search it will launch, if any). This means that in a simple game you typically get at most a single 'go' command, which effectively starts the search for all moves of that player in that game. Or you never get any 'go' command at all, because the 'new' command for starting a game already switches the engine to BLACK. So if the engine must play a game as black, you only ever have to send it moves.

[lucasart]

This introduction of the 'usermove' command in v2 of the protocol makes this more obvious. It also removes the parsing problem you mentioned: with the 'usermove' command you never have to guess whether an input token will be a move or a command; the first token on any line will always be the command keyword, and moves can only occur as an argument to the 'usermove' command. The engine must be able to process this command in all of the 4 modes. For backward-compatibility reasons the use of the 'usermove' command by the GUI must be switched on through 'feature usermove=1', just like the use of 'setboard' for loading positions has to be requested explicitly.

But this does not solve the parsing problem. You just made it worse by accepting both: CECP v2 accepts "MOVE" and "usermove MOVE", the latter being only allowed if the engine has "feature usermove=1". So you make the engine code yet more complicated, because it has to deal with both.

Are there any actively developped engines that use CECP v2 with usermove ?

[lucasart]

Another problem I found is the level command. Let's just look at the BASETIME:

The BASETIME parameter is in minutes, and can have the MIN:SEC notation.

I don't like about the above is the word "can". This means anything is allowed. An engine should expect MIN[:SEC] with MIN and SEC being integer, or floating points. All these are equally valid basetime CECP v2: "5:3", "0:303", "5.05".

Let me guess how this protocol was "designed":

• First we have BASETIME=minutes, which must be an integer.
• Second, we realise that BASETIME shouldn't have to be a multiple of 60 seconds, so we extend it to BASETIME=minutes:seconds, where minutes and seconds must be integers. This is backward compatible, and makes the engine code ever more complicated to write, in line with the CECP tradition.
• Third, we realise that the modern world (unlike the paleolithic world of CECP) demands milliseconds. Well, then, let's just allow floating points. But where should we put the floating point ? Shouldn't it be on SEC only and MIN should be integer ? Oh, well, now that all CECP engines do their own thing and don't respect the protocol anyway, let's just allow everything, so that we pretend to stay relevant even now...

[hgm]

But this does not solve the parsing problem. You just made it worse by accepting both: CECP v2 accepts "MOVE" and "usermove MOVE", the latter being only allowed if the engine has "feature usermove=1". So you make the engine code yet more complicated, because it has to deal with both.

Are there any actively developped engines that use CECP v2 with usermove ?

It is acceptable for engines to only accept v2 of the protocol. And a GUI should not be considered v2-compliant if it does not support at least the features ping, setboard, usermove and done. So there is no need to program for the possibility that these features are rejected. So there is no need to recognize bare moves when you send feature usermove=1, any more than that you need to implement the legacy 'edit' command if you send feature setboard=1.

I don't really know what other engines do. Of my own engines KingSlayer uses usermove, but Fairy-Max doesn't (and it also doesn't support setboard). It is no big deal to support both usermove and bare moves, btw., and when you run the engine from the command line (e.g. for debugging) it is very handy when you can omit the 'usermove'. If the second character of an input line is not alphabetic, the command is a move.

The important point of my message, though, was that 'force mode' is not a communication phase where a different set of commands (namely moves) applies (like the obsolete 'edit' mode really is: after 'edit' tou can only receive #, c or piece+square commands, until a . puts you back in normal mode). Moves are separate commands, that can arrive in any of the (non-edit) modes. So if the engine supports setboard, it only needs a single command loop, in which it must be able to recognize moves as well as other commands. It is just that after receiving a command, the engine must in principle always check whether it should launch a search, and if so, what type of search. This depends on the player mode, side to move and ponder setting. If the player mode is FORCE, then the engine will never search, irrespective of the stm or ponder setting.

All these are equally valid basetime CECP v2: "5:3", "0:303", "5.05".

Well, 5.05 is probably not OK; in the official CECP spec numbers are always integers. Sub-second base times are still rare even today. That does not hold for increments, though, so an extension of the 'level' command to allow fractions on that would be natural.

But sub-second timing is never recommended when not running on a bare machine; scheduling algorithms of operating systems would introduce a lot of noise, degrading the accuracy of the result. For fast test I developed another method, sometimes refered to as TIN (Time Is Nodes). There exists a feature nps, which allows the GUI to send an 'nps' command to the engine for defining nodes as a unit of time measurement, specifying the equivalence. The engine can then interpret the settings specified in the 'level' command as the equivalent number of nodes. If an engine typically runs at 1Mnps, setting it to 'nps 1' effectively redefines the time unit as micro-seconds. And no high-accuracy timers are needed, and it is completely insensitive to communication or scheduling delays.