Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Forsyth Notation Explained

Author: Bruce Moreland

Date: 09:10:14 04/17/99

Go up one level in this thread



On April 17, 1999 at 11:19:12, José de Jesús García Ruvalcaba wrote:

>On April 17, 1999 at 10:47:55, Bruce Moreland wrote:
>
>>
>>On April 17, 1999 at 08:31:06, Peter Klausler wrote:
>>
>>>> The hyphen following the "KQkq" could also be a square, for instance e3, which
>>>> is the target of an en-passant capture, if one is legal.
>>>
>>>No need for a square to define en-passant opportunities;
>>>the name of the file suffices.
>>
>>I'm not describing how it should be, I'm describing the standard as it exists.
>>
>>bruce
>
>	In fact, the en-passant square is indicated always when the last move was a
>pawn advancing two squares, regardless if it can actually be captured en-passant
>or not. I.e. hte requirement is not the existence of a legal en-passant capture,
>but the immediate previous advance of a pawn two squares.
>José.

Yeah, I think that is true.  It results in some strangeness when you are talking
about EPD though.

In an EPD line, if you include a "bm" (best move) tag, the move needs to be in
standard algebraic (SAN), which involves very strict disambiguation.  As an
example, if there is a knight on c3, pinned to the king on e1 by a bishop on b4,
and there is another knight on g1, in standard algebraic you say "Ne2" to move
the g1 knight to e2, rather than "Nge2", the reason being that Nce2 is illegal.

I'm not disagreeing with this, it's better than the alternative, which would be
force the (pseudo-)disambiguating "g".  This would make people to take into
account illegal moves when writing a disambiguator, and that's just painful and
bad.  It should be possible to take a strictly legal move list and disambiguate
accurately based upon that, it may be that in some implementation you don't have
a pseudo-legal move list, and you shouldn't be forced to construct one.

The problem is that the "bm" tag is done right, and yet there is no legality
checking done on the en-passant square in the FEN.

No big deal, but the result is that you get absolutely correct EPD files that
contain data that you have to verify and discard.

Also, by the same argument I used about not having to generate a pseudo-legal
move list in order to create SAN, you shouln't have to keep an en-passant square
in your implementation, when in fact the square is bogus.

I don't think that my program could produce a strictly legal FEN list for a real
game, it would strip the bogus en-passant squares out.  It's a drag to have to
remember illegal conditions in order to generate legal statements.

bruce



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.