Bug in xboard's protover 2 SAN output

[sje]

I was surprised to see this one:
[d] r1b1kb1r/p2p1ppp/4p3/1p2PP2/Pn2K1n1/2N4N/1PpP1qPP/R1B4R b kq - 8 13
The old Symbolic is playing White against the new Symbolic playing Black through xboard in a test game.

From the logs:

White sees the mate in one and sends:

Code: Select all

2009.04.01 17:30:31.244495 > move exf5#
2009.04.01 17:30:31.244536 > 0-1 {White is checkmated}

Black, however, gets:

Code: Select all

2009.04.01 17:30:31.247 < time 5925
2009.04.01 17:30:31.258 < otim 3821
2009.04.01 17:30:31.269 < usermove exf5+

For some unknown reason, xboard-4.2.7 is changing the mate indicator into a check indicator. This messes with the new Symbolic who is assuming that xboard understands SAN.

Is there a newer version of xboard that I should be using?

[krazyken]

you can certainly try the 4.3 series from HGM found at the Winboard Forum. Works for me on my Mac.

[sje]

you can certainly try the 4.3 series from HGM found at the Winboard Forum. Works for me on my Mac.

Thanks, I'll give it a try.

I reposted the original article at: http://www.open-aurec.com/wbforum/viewt ... 19&t=50062

[hgm]

This has nothing to do with the SAN generator, but with the mate detector. This 'bug' has been reported many times, and Tim Mann then always replies that it is not a bug but a 'documented limitation'. XBoard 4.2.7 is not e.p.-aware, and assumes all conceivabe e.p. rights always exist (to prevent it from refusing perfectly legal e.p. captures). In his position it assumes the check ca be resolved by 'e5xf6 e.p.', and thus it is not considered a mate.

XBoard 4.3, which is e.p. and castling aware, does not suffer from this 'limitation'.

What the program providing the move said about it, is of course ignored. That program might have sent the move not as SAN, but as 'e6f5'. Or there might not have been a program sending the move as all, and it might have been entered by dragging the Pawn with the mouse. So XBoard generates the SAN from scratch, by analysng the position.

Perhaps a SAN expert can answer this: is the check/mate indicator in SAN really redundant? The XBoard parser treats it as such, stripping any +, ++ or # suffix from the input move before parsing it. But if I have the following position:

[d]r6k/ppp4p/2q5/8/8/8/1R5R/B5K1 w

If I play Rb2-c2+, is it mandatory to use a disambiguator 'Rbc2+', or is the fact that I use the check indicator considered sufficient for specifying it must be the Rook on b2 that made the move, and can I simply say 'Rc2+'?

[sje]

The reason that Symbolic has been using xboard for years without triggering the bug is that Symbolic has always had the Capablanca Feature (i.e., Capablanca was *never* checkmated; he always resigned before an opponent could get a mate-in-one). It is only because I'm testing the new Symbolic core with the CF deactivated that a mate-in-one actually made it through xboard.

--------

[d] r6k/ppp4p/2q5/8/8/8/1R5R/B5K1 w - - 0 1

The moves are:

Code: Select all

Kf1 Kf2 Ra2+ Rb1+ Rb3+ Rb4+ Rb5+ Rb6+ Rbc2+ Rbd2+ Rbe2+ Rbf2+ Rbg2+ Rh1 Rh3 Rh4 Rh5 Rh6 Rhc2 Rhd2 Rhe2 Rhf2 Rhg2 Rxb7+ Rxh7+

Check and checkmate indications are not considered significant with respect to rank digit and file letter disambiguation.

[hgm]

Check and checkmate indications are not considered significant with respect to rank digit and file letter disambiguation.

OK, then XBoard treats them correctly. by simply ignoring them.

[Sven]

White sees the mate in one and sends:

Code: Select all

2009.04.01 17:30:31.244495 > move exf5#
2009.04.01 17:30:31.244536 > 0-1 {White is checkmated}

Black, however, gets:

Code: Select all

2009.04.01 17:30:31.247 < time 5925
2009.04.01 17:30:31.258 < otim 3821
2009.04.01 17:30:31.269 < usermove exf5+

I guess you probably mean "Black sees the mate in one and sends:" and "White, however, gets:", respectively.
Just for completeness, while the main issue itself has already been solved.

Sven

[sje]

I guess you probably mean "Black sees the mate in one and sends:" and "White, however, gets:", respectively.
Just for completeness, while the main issue itself has already been solved.

Yes, you're right.

--------

I'm now trying to move the programs and the scripts from 4.2.7.1 over to 4.3.15.

[bob]

The reason that Symbolic has been using xboard for years without triggering the bug is that Symbolic has always had the Capablanca Feature (i.e., Capablanca was *never* checkmated; he always resigned before an opponent could get a mate-in-one). It is only because I'm testing the new Symbolic core with the CF deactivated that a mate-in-one actually made it through xboard.

--------

[d] r6k/ppp4p/2q5/8/8/8/1R5R/B5K1 w - - 0 1

The moves are:

Code: Select all

Kf1 Kf2 Ra2+ Rb1+ Rb3+ Rb4+ Rb5+ Rb6+ Rbc2+ Rbd2+ Rbe2+ Rbf2+ Rbg2+ Rh1 Rh3 Rh4 Rh5 Rh6 Rhc2 Rhd2 Rhe2 Rhf2 Rhg2 Rxb7+ Rxh7+

Check and checkmate indications are not considered significant with respect to rank digit and file letter disambiguation.

In this case, Crafty would happily accept Rc2+. But it will not produce that move, and will produce Rbc2+ instead...

[bob]

White sees the mate in one and sends:

Code: Select all

2009.04.01 17:30:31.244495 > move exf5#
2009.04.01 17:30:31.244536 > 0-1 {White is checkmated}

Black, however, gets:

Code: Select all

2009.04.01 17:30:31.247 < time 5925
2009.04.01 17:30:31.258 < otim 3821
2009.04.01 17:30:31.269 < usermove exf5+

I guess you probably mean "Black sees the mate in one and sends:" and "White, however, gets:", respectively.
Just for completeness, while the main issue itself has already been solved.

Sven

I don't really care about this "bug" at all. Crafty knows when it is mated, and does not even parse the # flag anyway, it just strips it off. It does pay attention to the check indicator (+) and uses that to disambiguate moves, as if you give a +, it can immediately cull all non-checking moves before trying to match your input to the move generator's output.