Gothmog 0.4.8 en-passant bug

[Martin Baumung]

Geschrieben von:/Posted by: Martin Baumung at 03. June 2004 08:37:

Hi Tord, hi all,
while solving a moremover chess problem I noticed that some engines have serious problems with this position - obviously because of the possible en passant move.
Here is the initial position of that problem:
Mate in 16
Tomislav Petrovic & Radovan Tomasevic, 1997

abcdefgh8877665544332211abcdefgh(10/8) SMIRF FullChess FEN-Editor (© by R. Scharnagl) Ver. 1.4.0

kBb5/PpPp1p1p/1p1P1P1P/1P3PpK/8/8/8/6R1 w - g6 0 1
I don't know whether Gothmog supports "en-passant" at all since it doesn't find the correct move 1.f5xg6/ep, but when analyzing the above position after the move 1.f5xg6/ep Gothmog just gets completely lost.
It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move. Gothmog plays 1. ..Tg1h1 here - illegal of course.
But Gothmog is not alone
Best,
Martin

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 03 June 2004 12:18:44:
Als Antwort auf:/In reply to: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Martin Baumung at 03. June 2004 08:37:

Hi Tord, hi all,
while solving a moremover chess problem I noticed that some engines have serious problems with this position - obviously because of the possible en passant move.
Here is the initial position of that problem:
Mate in 16
Tomislav Petrovic & Radovan Tomasevic, 1997

abcdefgh8877665544332211abcdefgh(10/8) SMIRF FullChess FEN-Editor (© by R. Scharnagl) Ver. 1.4.0

kBb5/PpPp1p1p/1p1P1P1P/1P3PpK/8/8/8/6R1 w - g6 0 1
I don't know whether Gothmog supports "en-passant" at all since it doesn't find the correct move 1.f5xg6/ep, but when analyzing the above position after the move 1.f5xg6/ep Gothmog just gets completely lost.
It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Hi Martin,
Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.
Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 03 June 2004 12:48:54:
Als Antwort auf:/In reply to: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Martin Baumung at 03. June 2004 08:37:

Hi Tord, hi all,
while solving a moremover chess problem I noticed that some engines have serious problems with this position - obviously because of the possible en passant move.
Here is the initial position of that problem:
Mate in 16
Tomislav Petrovic & Radovan Tomasevic, 1997

abcdefgh8877665544332211abcdefgh(10/8) SMIRF FullChess FEN-Editor (© by R. Scharnagl) Ver. 1.4.0

kBb5/PpPp1p1p/1p1P1P1P/1P3PpK/8/8/8/6R1 w - g6 0 1
I don't know whether Gothmog supports "en-passant" at all since it doesn't find the correct move 1.f5xg6/ep, but when analyzing the above position after the move 1.f5xg6/ep Gothmog just gets completely lost.
It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move. Gothmog plays 1. ..Tg1h1 here - illegal of course.
But Gothmog is not alone
Best,
Martin

Movei also does not support it.
The reason is the same like gothmog.
If you want to analyze this position give the computer the position one ply earlier and make the pawn move in force mode and after it give the program to analyze it.
Uri

[Matthias Gemuh]

Geschrieben von:/Posted by: Matthias Gemuh at 03 June 2004 13:44:01:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Tord Romstad at 03 June 2004 12:18:44:

Hi Tord, hi all,
while solving a moremover chess problem I noticed that some engines have serious problems with this position - obviously because of the possible en passant move.
Here is the initial position of that problem:
Mate in 16
Tomislav Petrovic & Radovan Tomasevic, 1997

abcdefgh8877665544332211abcdefgh(10/8) SMIRF FullChess FEN-Editor (© by R. Scharnagl) Ver. 1.4.0

kBb5/PpPp1p1p/1p1P1P1P/1P3PpK/8/8/8/6R1 w - g6 0 1
I don't know whether Gothmog supports "en-passant" at all since it doesn't find the correct move 1.f5xg6/ep, but when analyzing the above position after the move 1.f5xg6/ep Gothmog just gets completely lost.
It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Hi Martin,
Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.
Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.




BigLion + Taktix

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 03 June 2004 14:05:51:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Matthias Gemuh at 03 June 2004 13:44:01:

Hi Tord, hi all,
while solving a moremover chess problem I noticed that some engines have serious problems with this position - obviously because of the possible en passant move.
Here is the initial position of that problem:
Mate in 16
Tomislav Petrovic & Radovan Tomasevic, 1997

abcdefgh8877665544332211abcdefgh(10/8) SMIRF FullChess FEN-Editor (© by R. Scharnagl) Ver. 1.4.0

kBb5/PpPp1p1p/1p1P1P1P/1P3PpK/8/8/8/6R1 w - g6 0 1
I don't know whether Gothmog supports "en-passant" at all since it doesn't find the correct move 1.f5xg6/ep, but when analyzing the above position after the move 1.f5xg6/ep Gothmog just gets completely lost.
It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Hi Martin,
Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.
Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

[Matthias Gemuh]

Geschrieben von:/Posted by: Matthias Gemuh at 03 June 2004 16:21:14:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Uri Blass at 03 June 2004 14:05:51:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.


The UCI specification therefore seems to need some correction !
/Matthias.





BigLion + Taktix

[Richard Pijl]

Geschrieben von:/Posted by: Richard Pijl at 03 June 2004 16:37:07:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Matthias Gemuh at 03 June 2004 16:21:14:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

[Martin Baumung]

Geschrieben von:/Posted by: Martin Baumung at 03 June 2004 16:47:54:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Richard Pijl at 03 June 2004 16:37:07:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

Hello Richard,
that's in agreement with what I have observed with Arena. When starting in the position mentioned above strange things happen with various engines (Gothmog, YACE, SmarThink).
When starting from the position
kBb5/PpPp1ppp/1p1P1P1P/1P3P1K/8/8/8/6R1 b - - 0 1
however, and manually entering the move 1. ..g7-g5 afterwards, everything is fine. So Arena obviously sends the initial FEN-string without any possible en-passant caputre plus the move made.
Best,
Martin

[David Dahlem]

Geschrieben von:/Posted by: David Dahlem at 03 June 2004 16:57:55:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Martin Baumung at 03 June 2004 16:47:54:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

Hello Richard,
that's in agreement with what I have observed with Arena. When starting in the position mentioned above strange things happen with various engines (Gothmog, YACE, SmarThink).
When starting from the position
kBb5/PpPp1ppp/1p1P1P1P/1P3P1K/8/8/8/6R1 b - - 0 1
however, and manually entering the move 1. ..g7-g5 afterwards, everything is fine. So Arena obviously sends the initial FEN-string without any possible en-passant caputre plus the move made.
Best,
Martin

After pasting this fen string in Arena, some engines find the Mate in 1 and some engines never find the Mate in 1. So obviously Arena does send the en passant capture square.
5K2/8/2qk4/2nPp3/3r4/6B1/B7/3R4 w - e6 0 1
Regards
Dave

[Matthias Gemuh]

Geschrieben von:/Posted by: Matthias Gemuh at 03 June 2004 17:05:35:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Richard Pijl at 03 June 2004 16:37:07:

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

No !! Shredder Classic GUI (don't know if latest also) sends FENs instead
of previous moves. I noticed this in some version about 1.5 years ago and
have never further investigated the issue.
/Matthias.


BigLion + Taktix

[Martin Baumung]

Geschrieben von:/Posted by: Martin Baumung at 03 June 2004 17:07:20:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: David Dahlem at 03 June 2004 16:57:55:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

Hello Richard,
that's in agreement with what I have observed with Arena. When starting in the position mentioned above strange things happen with various engines (Gothmog, YACE, SmarThink).
When starting from the position
kBb5/PpPp1ppp/1p1P1P1P/1P3P1K/8/8/8/6R1 b - - 0 1
however, and manually entering the move 1. ..g7-g5 afterwards, everything is fine. So Arena obviously sends the initial FEN-string without any possible en-passant caputre plus the move made.
Best,
Martin

After pasting this fen string in Arena, some engines find the Mate in 1 and some engines never find the Mate in 1. So obviously Arena does send the en passant capture square.
5K2/8/2qk4/2nPp3/3r4/6B1/B7/3R4 w - e6 0 1
Regards
Dave

Yes, sorry if my previous posting sounds mistakable. It's not the GUI's fault. Some engines (Gothmog, SmarThink) just don't care about the ep-sqare in the FEN-String while other engines like YACE apparently do but still get confused.
Best,
Martin

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 03 June 2004 17:19:18:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Martin Baumung at 03 June 2004 17:07:20:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

Hello Richard,
that's in agreement with what I have observed with Arena. When starting in the position mentioned above strange things happen with various engines (Gothmog, YACE, SmarThink).
When starting from the position
kBb5/PpPp1ppp/1p1P1P1P/1P3P1K/8/8/8/6R1 b - - 0 1
however, and manually entering the move 1. ..g7-g5 afterwards, everything is fine. So Arena obviously sends the initial FEN-string without any possible en-passant caputre plus the move made.
Best,
Martin

After pasting this fen string in Arena, some engines find the Mate in 1 and some engines never find the Mate in 1. So obviously Arena does send the en passant capture square.
5K2/8/2qk4/2nPp3/3r4/6B1/B7/3R4 w - e6 0 1
Regards
Dave

Yes, sorry if my previous posting sounds mistakable. It's not the GUI's fault. Some engines (Gothmog, SmarThink) just don't care about the ep-sqare in the FEN-String while other engines like YACE apparently do but still get confused.
Best,
Martin

It is certainly the GUI's fault because it could translate FEN with ep-square to a FEN without ep-square and a move and send the information to the engine.
I decided not to support the ep square because I think that there is no reason to do it when people can give the engine the position one ply earlier and the move.
Uri

[Martin Baumung]

Geschrieben von:/Posted by: Martin Baumung at 03 June 2004 17:19:25:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Matthias Gemuh at 03 June 2004 17:05:35:

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

No !! Shredder Classic GUI (don't know if latest also) sends FENs instead
of previous moves. I noticed this in some version about 1.5 years ago and
have never further investigated the issue.
/Matthias.

It obviously is fixed in the latest release. When starting from the position
kBb5/PpPp1ppp/1p1P1P1P/1P3P1K/8/8/8/6R1 b - - 0 1
and moving the pawn from g7 to g5 manually everything works fine with Gothmog under Shredder Classic GUI. Therefore it obviously doesn't send the FEN-String only.
Best,
Martin

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 03 June 2004 17:21:20:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Richard Pijl at 03 June 2004 16:37:07:

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

Yes.
Here a request for tournament directors who didn't follow this piece of advice already:
Never use FEN for Nunn-like matches, always PGN (WinBoard supports this).
Even stateless UCI-only engines will miss repetition detection, as Uri pointed out.
Fabien.
PS: PolyGlot sends the whole move list, of course.

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 03 June 2004 17:22:20:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Uri Blass at 03 June 2004 17:19:18:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

Hello Richard,
that's in agreement with what I have observed with Arena. When starting in the position mentioned above strange things happen with various engines (Gothmog, YACE, SmarThink).
When starting from the position
kBb5/PpPp1ppp/1p1P1P1P/1P3P1K/8/8/8/6R1 b - - 0 1
however, and manually entering the move 1. ..g7-g5 afterwards, everything is fine. So Arena obviously sends the initial FEN-string without any possible en-passant caputre plus the move made.
Best,
Martin

After pasting this fen string in Arena, some engines find the Mate in 1 and some engines never find the Mate in 1. So obviously Arena does send the en passant capture square.
5K2/8/2qk4/2nPp3/3r4/6B1/B7/3R4 w - e6 0 1
Regards
Dave

Yes, sorry if my previous posting sounds mistakable. It's not the GUI's fault. Some engines (Gothmog, SmarThink) just don't care about the ep-sqare in the FEN-String while other engines like YACE apparently do but still get confused.
Best,
Martin

It is certainly the GUI's fault because it could translate FEN with ep-square to a FEN without ep-square and a move and send the information to the engine.
I decided not to support the ep square because I think that there is no reason to do it when people can give the engine the position one ply earlier and the move.
Uri

People can claim by the same logic that programs do not need to support FEN because it is possible to get every legal position by a sequence of moves from the opening position but in this case the task is not trivial to do for a gui so I reject it.
Uri

[David Dahlem]

Geschrieben von:/Posted by: David Dahlem at 03 June 2004 17:25:59:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Uri Blass at 03 June 2004 17:19:18:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

Hello Richard,
that's in agreement with what I have observed with Arena. When starting in the position mentioned above strange things happen with various engines (Gothmog, YACE, SmarThink).
When starting from the position
kBb5/PpPp1ppp/1p1P1P1P/1P3P1K/8/8/8/6R1 b - - 0 1
however, and manually entering the move 1. ..g7-g5 afterwards, everything is fine. So Arena obviously sends the initial FEN-string without any possible en-passant caputre plus the move made.
Best,
Martin

After pasting this fen string in Arena, some engines find the Mate in 1 and some engines never find the Mate in 1. So obviously Arena does send the en passant capture square.
5K2/8/2qk4/2nPp3/3r4/6B1/B7/3R4 w - e6 0 1
Regards
Dave

Yes, sorry if my previous posting sounds mistakable. It's not the GUI's fault. Some engines (Gothmog, SmarThink) just don't care about the ep-sqare in the FEN-String while other engines like YACE apparently do but still get confused.
Best,
Martin

It is certainly the GUI's fault because it could translate FEN with ep-square to a FEN without ep-square and a move and send the information to the engine.
I decided not to support the ep square because I think that there is no reason to do it when people can give the engine the position one ply earlier and the move.
Uri

How can it be the GUI's fault when it is supporting the FEN standard? If anything, it is the fault of the FEN standard.
Regards
Dave

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 03 June 2004 17:34:32:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: David Dahlem at 03 June 2004 17:25:59:

Thanks for letting me know. The problem is simply that Gothmog doesn't
understand en passant squares in FEN strings. I've simply been too lazy
to implement this so far.
I'll have a look at it before the next version is released.

It doesn't show any more moves for black in the main line. Imagine this situation (or a similar one) coming up in a regular match, Gothmog would lose instantly because of an illegal move.

Fortunately it cannot happen in a regular match, because regular matches
never start from a FEN position where an en passant capture is possible.

Tord

"Fortunately it cannot happen in a regular match, because ..." ?
Shredder Classic UCI GUI sends FENs to engines in regular matches,
instead of move lists.
/Matthias.

It means that people should not use shredder classic GUI.
Other problems can happen.
A program can go for repetition because of getting FEN and not knowing that it goes for repetition.
What in case that the program is using the previous moves for decision about better evaluation or better search decisions?
With Fen I see no way to do it.
Uri

* position [fen | startpos ] moves ....
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

The UCI specification therefore seems to need some correction !

AFAIK the GUI should send all the moves that have been played before the current position. The fen is only sent when the 'game' didn't start in the initial position and the previous moves are not known by the GUI.
Richard.

Hello Richard,
that's in agreement with what I have observed with Arena. When starting in the position mentioned above strange things happen with various engines (Gothmog, YACE, SmarThink).
When starting from the position
kBb5/PpPp1ppp/1p1P1P1P/1P3P1K/8/8/8/6R1 b - - 0 1
however, and manually entering the move 1. ..g7-g5 afterwards, everything is fine. So Arena obviously sends the initial FEN-string without any possible en-passant caputre plus the move made.
Best,
Martin

After pasting this fen string in Arena, some engines find the Mate in 1 and some engines never find the Mate in 1. So obviously Arena does send the en passant capture square.
5K2/8/2qk4/2nPp3/3r4/6B1/B7/3R4 w - e6 0 1
Regards
Dave

Yes, sorry if my previous posting sounds mistakable. It's not the GUI's fault. Some engines (Gothmog, SmarThink) just don't care about the ep-sqare in the FEN-String while other engines like YACE apparently do but still get confused.
Best,
Martin

It is certainly the GUI's fault because it could translate FEN with ep-square to a FEN without ep-square and a move and send the information to the engine.
I decided not to support the ep square because I think that there is no reason to do it when people can give the engine the position one ply earlier and the move.
Uri

How can it be the GUI's fault when it is supporting the FEN standard? If anything, it is the fault of the FEN standard.
Regards
Dave

The fault is expecting the engines to support FEN correctly when it could be expected that a lot of people will not support it correctly.
Uri

[Alex Schmidt]

Geschrieben von:/Posted by: Alex Schmidt at 03 June 2004 17:36:31:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Matthias Gemuh at 03 June 2004 13:44:01:

Hello Matthias,

Shredder Classic UCI GUI sends FENs to engines in regular matches,

How did you observe this?
Here is a part of a Logfile:
Thu Jun 03 17:21:10 2004: to xxx (1): ucinewgame
Thu Jun 03 17:21:10 2004: to xxx (1): isready
Thu Jun 03 17:21:10 2004: from xxx (1): readyok
Thu Jun 03 17:21:10 2004: to xxx (1): position startpos moves d2d4 g8f6 c2c4 e7e6 b2b4
Thu Jun 03 17:21:10 2004: to xxx (1): go wtime 292818 btime 299876
Played with a GUI book, everything seems OK for me. Maybe someone played games with startpositions from a fen position?
Best,
Alex

[Matthias Gemuh]

Geschrieben von:/Posted by: Matthias Gemuh at 03 June 2004 17:51:52:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Alex Schmidt at 03 June 2004 17:36:31:

Hello Matthias,

Shredder Classic UCI GUI sends FENs to engines in regular matches,

How did you observe this?
Here is a part of a Logfile:
Thu Jun 03 17:21:10 2004: to xxx (1): ucinewgame
Thu Jun 03 17:21:10 2004: to xxx (1): isready
Thu Jun 03 17:21:10 2004: from xxx (1): readyok
Thu Jun 03 17:21:10 2004: to xxx (1): position startpos moves d2d4 g8f6 c2c4 e7e6 b2b4
Thu Jun 03 17:21:10 2004: to xxx (1): go wtime 292818 btime 299876
Played with a GUI book, everything seems OK for me. Maybe someone played games with startpositions from a fen position?
Best,
Alex

Hi Alex,
it was in ordinary engine-engine matches (nothing pasted).
I would have to install at least Shredder6Classic again to find out.
If I do it, I will inform in this forum.
Best,
Matthias.


BigLion + Taktix

[Alex Schmidt]

Geschrieben von:/Posted by: Alex Schmidt at 03 June 2004 18:09:05:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 en-passant bug geschrieben von:/posted by: Matthias Gemuh at 03 June 2004 17:51:52:

Hi Matthias,
of course I believe you. The log was from the latest Classic GUI, so it seems to be fixed now.
I thought you got maybe logs from a tester.
Best,
Alex