test suites
James Long
Would someone explain what "KQ" or just "k" means in a test suite?
I know it's the castling rights, but not sure what the possibilities
are. Seems "kq" would mean "black can castle queenside" but when
I set the position up it *appeared* black could castle either way....
what are the other castling possibilities?
I know the position is displayed first, from A8 to H1, then
player to move, castling rights.... where would en passant
options come in? After castling rights?
Thanks for the help. :)
Sorry if this post is a duplicate...having problems with my news server.
James
Samuel Slutzky
James Long (wzrd...@fia.net) wrote:
: Would someone explain what "KQ" or just "k" means in a test suite?
: I know it's the castling rights, but not sure what the possibilities
: are. Seems "kq" would mean "black can castle queenside" but when
: I set the position up it *appeared* black could castle either way....
: what are the other castling possibilities?
The best bet is to get the EPD standard file from
ftp://caissa.onenet.net/pub/chess/PGN/EPD_Kit.tar.gz, if that is the
right file. I am not sure where the text file describing EPD went.
Anyway, AFAIK, after the board position is read in, you have two fields
representing castling and en passant. The first field is either, "-" for
no castling possible or contains any of "K", "Q", "k", or "q" where the
upper-case letters refer to white's kingside and queenside castling
possibilities respectively, and the lower-case letters refer to black's
castling possibilities. As for your next question about en passant, this
is indicated in the following field as either a "-", again for no en
passant captures possible, or a letter "a" through "h", representing the
file where an en passant capture is available. I hope that helps.
Sam Slutzky
: I know the position is displayed first, from A8 to H1, then
Robert Hyatt
James Long (wzrd...@fia.net) wrote:
: Would someone explain what "KQ" or just "k" means in a test suite?
: I know it's the castling rights, but not sure what the possibilities
: are. Seems "kq" would mean "black can castle queenside" but when
: I set the position up it *appeared* black could castle either way....
: what are the other castling possibilities?
: I know the position is displayed first, from A8 to H1, then
: player to move, castling rights.... where would en passant
: options come in? After castling rights?
: Thanks for the help. :)
: Sorry if this post is a duplicate...having problems with my news server.
: James
KQ does, as you suspect, mean white can castle either way, while k would
mean black can only castle king-side (if the rook is on a8, then it must
have been moved to lose the right to castle.)
enpassant comes next. To omit castling, you generally see -.
ditto for en passant captures if none are possible. Beware of the
EP target, however, because some use it differently. For example,
on ICC, when you parse a "style 12" you get an "en passant file"
indicator. Even when no en passant capture is possible. It is
simply set when a pawn moves two squares. I have seen similar EPD
positions where an en passant target was given, but no en passant
capture was actually possible. Shouldn't happen, of course, but
early versions of Crafty were very "trusting".... and it led to some
interesting debugging sessions.. :)
brucemo
Marcel van Kervinck wrote:
>
> brucemo (bru...@nwlink.com) wrote:
> > > So, after White plays pawn from e2 to e4, the ep target field is "e3".
> > > After Black plays pawn from d7 to d5, the field is "d6". Note that
> > > the placement of other pawns to take advantage of an en passant
> > > capture has no effect on the recording of the target square.
>
> > I don't like this.
>
> > If black plays Bb4 and there is a white knight on c3 and another one on
> > g1, and the c3 knight is pinned against the king, the SAN for g1-e2 is
> > "Ne2" and not "Nge2". Moves are disambiguated based upon their
> > legality, not upon how easy it is for a computer to determine their
> > legality.
>
> I have no problem with that. For generating SAN, it's slightly more
> expensive. But for reading SAN and SAN look-a-likes it doesn't
> really matter. I think a program should be able to accept both.
> This convention is also used in the chess literature. Here I think
> Steven made the right design desision to disambiguate on legality.
I agree that this was the right way to do it. If I had a program that by
chance did *only* generate legal moves, I wouldn't want to have to try to
hack it up so that it could generate artificial ambiguities when writing a
PGN file.
It's better to force everyone to standardize on buglessness than on
bugginess.
> > Likewise, if the last move was e2-e4, and an en-passant capture is not
> > legal, the en-passant field in an EPD or a FEN *should* have to be "-".
>
> That's clearly a pain, I agree. I think it would be wise to revise
> EPD and FEN on this point. Steven?
Since I said something about the other paragraph, I may as well say something
more here, too.
A reason that I don't like this implementation is that I once got ahold of
some positions where the en-passant square was set when an en-passant capture
was not legal (or even pseudo-legal). My program ate these positions and
barfed, because internally it doesn't set the en-passant square unless an
en-passant capture is pseudo-legal (meaning there is pawn there that could
move to the en-passant square, although to do so it might leave you in
check).
There are some aspects of EPD that you can be flexible about. To be sure,
I'll make my program eat "8/8/k/8/KP w - - 0 1" the same as it will eat
"8/8/k7/8/KP6/8/8/8 w - - 0 1", and I should also make it eat FENs that have
bogus en-passant squares and castling flags, but there's no reason not to
specify that they at least *should* be correct.
bruce
Marcel van Kervinck
brucemo (bru...@nwlink.com) wrote:
> > So, after White plays pawn from e2 to e4, the ep target field is "e3".
> > After Black plays pawn from d7 to d5, the field is "d6". Note that
> > the placement of other pawns to take advantage of an en passant
> > capture has no effect on the recording of the target square.
> I don't like this.
> If black plays Bb4 and there is a white knight on c3 and another one on
> g1, and the c3 knight is pinned against the king, the SAN for g1-e2 is
> "Ne2" and not "Nge2". Moves are disambiguated based upon their
> legality, not upon how easy it is for a computer to determine their
> legality.
I have no problem with that. For generating SAN, it's slightly more
expensive. But for reading SAN and SAN look-a-likes it doesn't
really matter. I think a program should be able to accept both.
This convention is also used in the chess literature. Here I think
Steven made the right design desision to disambiguate on legality.
> Likewise, if the last move was e2-e4, and an en-passant capture is not
> legal, the en-passant field in an EPD or a FEN *should* have to be "-".
That's clearly a pain, I agree. I think it would be wise to revise
EPD and FEN on this point. Steven?
Marcel
-- _ _
_| |_|_|
|_ |_ Marcel van Kervinck
|_| mar...@stack.nl