Strange time allocation at the start of FRC game (SF 2.1.1)

[dranke]

I must be doing something wrong...

While testing some code to do engine matches, I ran across the following:

Code: Select all

dranke@dranke-desktop:~$ stockfish
Stockfish 2.1.1 64bit by Tord Romstad, Marco Costalba and Joona Kiiski
Good! CPU has hardware POPCNT.
setoption name UCI_Chess960 value true
position fen brkbrnnq/pppppppp/8/8/8/8/PPPPPPPP/BRKBRNNQ w EBeb - 0 0
go wtime 10000 btime 10000 winc 100 binc 100
info depth 1
info depth 1 seldepth 1 multipv 1 score cp 68 nodes 41 nps 1863 time 22 pv f1e3
[...]
info depth 20 seldepth 26 multipv 1 score cp 12 nodes 40487117 nps 4151673 time 9752 pv e2e4 e7e5 f1e3 b7b5 d2d3 f8e6 b2b4 d7d6 g1h3 g8h6 d1e2 d8e7 e8g8 e8g8 c2c3 f7f5 e3d5 e7h4 g2g3 
info nodes 40487117 nps 4151673 time 9752
bestmove e2e4 ponder e7e5

Ie. stockfish with white uses 9.75s for its first move in a 10s+0.1s game.

And:

Code: Select all

dranke@dranke-desktop:~$ stockfish
Stockfish 2.1.1 64bit by Tord Romstad, Marco Costalba and Joona Kiiski
Good! CPU has hardware POPCNT.
setoption name UCI_Chess960 value true
position fen brkbrnnq/pppppppp/8/8/8/8/PPPPPPPP/BRKBRNNQ w EBeb - 0 0 moves e2e4
go wtime 10000 btime 10000 winc 100 binc 100
info depth 1
info depth 1 seldepth 1 multipv 1 score cp -12 nodes 42 nps 1500 time 28 pv e7e5 
info nodes 42 nps 1500 time 28
bestmove e7e5

Stockfish with black only goes to depth 1 on the first move.

Now, looking at the CCRL 40/4 FRC list, it doesn't seem plausible that FRC in stockfish 2.1.1 is this buggy, so I'm really trying to find a mistake in my UCI commands, but so far I have no idea what is going on here.

With stockfish 2.0.1, I don't get this behaviour, and after the first move, stockfish 2.1.1 also plays normally.

Any ideas are appreciated.

[mcostalba]

Any ideas are appreciated.

From FEN standard:

"Fullmove number: The number of the full move. It starts at 1, and is incremented after Black's move."

[mcostalba]

Any ideas are appreciated.

From FEN standard:

"Fullmove number: The number of the full move. It starts at 1, and is incremented after Black's move."

BTW, people be so kind to avoid stuff like "but the engine should validate the fen.." and the likes. Thanks in advance !

[dranke]

Oh no, I feel a bit stupid now...

And you are right, given invalid input, it'a perfectly fine for the output to be undefined.

Thanks.

[michiguel]

Oh no, I feel a bit stupid now...

And you are right, given invalid input, it'a perfectly fine for the output to be undefined.

Thanks.

Undefined behavior is not what UCI requires.

* if the engine receives a command which is not supposed to come, for example "stop" when the engine is not calculating, it should also just ignore it.

The appropriate behavior is to ignore the invalid input. Whether this is good or not, it's another issue.

Miguel

[mcostalba]

Oh no, I feel a bit stupid now...

And you are right, given invalid input, it'a perfectly fine for the output to be undefined.

Thanks.

Undefined behavior is not what UCI requires.

* if the engine receives a command which is not supposed to come, for example "stop" when the engine is not calculating, it should also just ignore it.

The appropriate behavior is to ignore the invalid input. Whether this is good or not, it's another issue.

Miguel

We already come to something similar in the past, but as it was used to say "repetita iuvant" so here it goes:

Miguel, the sentence you reported from UCI and your following supposed description say two different things.

We should have clear the difference between an "UCI command" and the command parameters or arguments.

A command is one thing, it is a UCI keyword among few ones. The parameters that follow the command are another thing. For instance SF correctly sticks to the UCI rule you reported, but not to your "explanation" of the rule, proofing that actually these are 2 different concepts.

[Sven]

Oh no, I feel a bit stupid now...

And you are right, given invalid input, it'a perfectly fine for the output to be undefined.

Thanks.

Undefined behavior is not what UCI requires.

* if the engine receives a command which is not supposed to come, for example "stop" when the engine is not calculating, it should also just ignore it.

The appropriate behavior is to ignore the invalid input. Whether this is good or not, it's another issue.

Miguel

We already come to something similar in the past, but as it was used to say "repetita iuvant" so here it goes:

Miguel, the sentence you reported from UCI and your following supposed description say two different things.

We should have clear the difference between an "UCI command" and the command parameters or arguments.

A command is one thing, it is a UCI keyword among few ones. The parameters that follow the command are another thing. For instance SF correctly sticks to the UCI rule you reported, but not to your "explanation" of the rule, proofing that actually these are 2 different concepts.

You are perfectly right, an invalid command is different from a valid command with invalid arguments, especially in the case where the arguments were supplied by the user or some external resource. This difference means:
- you can always ignore invalid commands, since they should not occur anyway;
- but you should always check user input.

Since you certainly will not allow to start a standard (or FRC) chess game with more than two kings on the board, or with pawns on the first rank, it does make sense to also perform the simplest checks for the other FEN parts, too. It is not required to create sophisticated error messages covering each possible case, but a simple range check is something that can increase the user's acceptance. Reading "Illegal FEN" is much more informative for the user than reading nothing and wondering why something unusual happens. And it is so easy to achieve

Just my 2 cents,
Sven

[mcostalba]

And it is so easy to achieve

Hi Sven,

I am not sure that fully validating a fen string is so easy to achieve. What is easy to achieve is half validating a FEN string, but this is a totally different concept.

When writing software you have two choices: take the responsibility for the correctness of the data you handle or do not take responsibility. You have not a third choice: take half responsibility, or take responsibility only for the easy parts. This line seems a joke and I have expressed a bit in a crude form, but I assure you it is a fundamental principle to write quality software, otherwise you just attempt to write software using the typical naive approach of the hobbyist. Writing quality software is much more than knowing the C/C++ rules !

For the most common software you should take responsibility for the input data, but for a chess engine this is not such an hard requirement. Nevertheless to say in SF we have chosen to not take responsibility of the validity of the input FEN string

[Sven]

Hi Marco,

an FEN is (almost) well-defined. Just stick with that definition and check everything that is listed there, and you are on the safe side. The key point is "ensure program integrity", i.e. avoid making user input crash, hang, or misbehave your program.

It is not stated that an FEN describing an unreachable position is "illegal", so you are free in this part which conditions you check and which you don't (e.g. piece counts, things like Ba1-Pb2 or Pa2-Pa3-Pb2). Setting up an unreachable position is usually unlikely to violate program integrity. But an FEN string describing a position that violates the chess rules (e.g. three kings - creates "checkmate" ambiguity) is obviously illegal and can easily affect integrity. En passant target squares are illegal in well-defined cases (apart from the well-known point about having an ep target without any adjacent enemy pawn), and a program that relies on either a correct ep square or no ep square can crash on a bad one. Characters in the castling rights part of the FEN that are not conforming to the spec are illegal. Negative numbers as fifty move counter or full move counter are illegal. And a zero as full move counter is illegal, too.

All of these checks are easy to be done, there is nothing tricky in it. I simply consider not applying all of them as "lazyness"

Those checks that do not affect integrity are often optional. And there you have your "half validation". It is really existing in the real world, there is more than just "black and white". But your program is better if it detects all that is "black" (i.e., would lead to a crash), and as much as possible and useful that is "grey". In this sense, unreachable positions are usually "grey" but "full move counter = 0" is clearly "black".

Sven

[hgm]

Why look at the move number at all? The engine should do exactly the sameno matter what the move number is, provided it is in the valid range. So doing strange things when it is out of range seems unnecessarily pedantic...