Code: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -
Code: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1
Miguel
PS: Is it the only one?
Moderators: hgm, Rebel, chrisw
Code: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -
Code: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1
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.michiguel wrote:From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends
When it should sendCode: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -
It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.Code: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1
Miguel
PS: Is it the only one?
UCI uses e1g1 notation for castling, you can't go very wrong there. the only downside is that it is incompatible with FRCDann Corbit wrote: 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
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.michiguel wrote:From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends
When it should sendCode: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -
It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.Code: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1
Actually UCI uses coordinate notation also for FRC - the target square is the rook's square.Edmund wrote:UCI uses e1g1 notation for castling, you can't go very wrong there. the only downside is that it is incompatible with FRCDann Corbit wrote: 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
That is not a problem in Shredder Linux (Demo)Houdini wrote: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.michiguel wrote:From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends
When it should sendCode: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -
It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.Code: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1
I've reported the issue to the Shredder support team.
Right.Dann Corbit wrote: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.michiguel wrote:From the Gaviota logs that Marc Halstern reported to me I found that Aquarium sends
When it should sendCode: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq -
It think this is a serious bug because it makes any engine who is strict about the UCI standard, unusable for analysis.Code: Select all
position fen r1bqk2r/pppp1pbp/2n2np1/4p3/2P5/2N2NP1/PP1PPPBP/R1BQK2R w KQkq - 0 1
Miguel
PS: Is it the only one?
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.