UCI Implementation of Aquarium is broken (FEN positions)

[michiguel]

From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -

When it should send

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1

It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.

Miguel
PS: Is it the only one?

[Dann Corbit]

From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -

When it should send

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1

It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.

Miguel
PS: Is it the only one?

I do not know for certain, but I suspect that many front ends do not send the half move clock or the 50 move counter. In these cases, if I were king of the forest, I would simply assume 0 1.

In other words, default the values to 0 1 and then over-ride them if some thoughtful interface should provide them as it ought.

You are also likely to see even worse things like zeros for castling:
0-0-0 and 0-0 instead of the correct O-O-O and O-O

There are other atrocities as well.

[Edmund]

You are also likely to see even worse things like zeros for castling:
0-0-0 and 0-0 instead of the correct O-O-O and O-O

UCI uses e1g1 notation for castling, you can't go very wrong there. the only downside is that it is incompatible with FRC

[Houdini]

From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -

When it should send

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1

It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.

Shredder GUI does exactly the same, and I agree that this is a serious bug. See this recent thread, it shows a position for which it is impossible to get the correct evaluation (draw) in Shredder.
I've reported the issue to the Shredder support team.

[ilari]

You are also likely to see even worse things like zeros for castling:
0-0-0 and 0-0 instead of the correct O-O-O and O-O

UCI uses e1g1 notation for castling, you can't go very wrong there. the only downside is that it is incompatible with FRC

Actually UCI uses coordinate notation also for FRC - the target square is the rook's square.

[michiguel]

From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -

When it should send

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1

It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.

Shredder GUI does exactly the same, and I agree that this is a serious bug. See this recent thread, it shows a position for which it is impossible to get the correct evaluation (draw) in Shredder.
I've reported the issue to the Shredder support team.

That is not a problem in Shredder Linux (Demo)


Miguel

[wgarvin]

From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -

When it should send

Code: Select all

position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1

It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.

Miguel
PS: Is it the only one?

I do not know for certain, but I suspect that many front ends do not send the half move clock or the 50 move counter. In these cases, if I were king of the forest, I would simply assume 0 1.

In other words, default the values to 0 1 and then over-ride them if some thoughtful interface should provide them as it ought.

You are also likely to see even worse things like zeros for castling:
0-0-0 and 0-0 instead of the correct O-O-O and O-O

There are other atrocities as well.

Right.

The golden rule of interoperability: Be as permissive as possible in what you accept as input, and as strict/canonical as possible in what you produce as output.

Yes, interfaces which are technically violating the spec should be fixed. However, they are out there and lots of people have the versions which violate the spec, and are not necessarily going to upgrade. Its often possible to interoperate with them anyway, by accepting their not-quite-conforming inputs. As long as this is not too burdensome, its a benefit to anyone who tries to use your engine with one of those interfaces.

Another example is interfaces with no winboard 2.0 support: they have no setboard, they can only use the edit commands and (IIRC) have no easy/standardized way to set things like castling status or enpassant square. But you can still "mostly" interoperate with them if you implement the edit commands and fall back to them when the interface doesn't support 2.0 and setboard -- you just have to decide if its worth the effort.