Gothmog 1.0 beta 13 FRC (Linux and OS X only)

[Tord Romstad]

Hi all,

In order to give Glaurung a new sparring partner while preparing for Mainz, I decided to resurrect Gothmog and implement the new UCI FRC extensions. I release it with the hope that it can be useful even for other FRC program authors using OS X or Linux.

For boring, technical reasons which I am too lazy to explain at the moment, the search information displayed by this version of Gothmog is quite badly broken. The PVs are often incomplete or wrong (except for the first move, which should always be correct), and the scores can not always be trusted.

Nevertheless, Gothmog 1.0 beta 13 seems to play annoyingly well, and gives the most recent beta version of Glaurung an awful lot of trouble. I've played 20 blitz games so far, and Gothmog is currently leading (!) by 11-9.

In order to use Gothmog 1.0 beta 13, you have to download the binary package (OS X and Linux executables included), XBoard-960, and the most recent PolyGlot beta.

Tord

[Tord Romstad]

Nevertheless, Gothmog 1.0 beta 13 seems to play annoyingly well, and gives the most recent beta version of Glaurung an awful lot of trouble. I've played 20 blitz games so far, and Gothmog is currently leading (!) by 11-9.

In the end, Glaurung still managed to win comfortably: When I stopped the match this morning, the score was 76-48. (Huge sigh of relief)

The games are among the strangest I have ever seen, and often don't look like chess at all. After twenty moves or so, it looks like the pieces have just been dropped randomly onto the board. Ugly, but fun to watch.

Tord

[Tord Romstad]

Nevertheless, Gothmog 1.0 beta 13 seems to play annoyingly well, and gives the most recent beta version of Glaurung an awful lot of trouble. I've played 20 blitz games so far, and Gothmog is currently leading (!) by 11-9.

In the end, Glaurung still managed to win comfortably: When I stopped the match this morning, the score was 76-48. (Huge sigh of relief)

The games are among the strangest I have ever seen, and often don't look like chess at all. After twenty moves or so, it looks like the pieces have just been dropped randomly onto the board. Ugly, but fun to watch.

Tord

[Reinhard Scharnagl]

Hi Tord,

Glaurung024 (Windows) still seems to have some troubles with castling. Maybe problems only exist under Arena, I don't know. I do not test your new version supporting Shredder's incompatible FEN, thus I also don't know, if there has been any progress.

As being announced in http://f23.parsimony.net/forum50826/messages/129919.htm by referee Ingo Alth?fer there are at least five programs awaited to have serious problems with Chess960 castlings.

I hope, that you will be able to fix those problems in time.

I am sorry, that SMIRF will not be participating there, though being full Chess960 aware (and much more), because of the compatible X-FEN no longer is the officially recommended way to encode Chess960 games and positions, thus opening the door for serious incompatibilities.

Reinhard.

[Tord Romstad]

Glaurung024 (Windows) still seems to have some troubles with castling. Maybe problems only exist under Arena, I don't know. I do not test your new version supporting Shredder's incompatible FEN, thus I also don't know, if there has been any progress.

Hi Reinhard,

Thanks for the information. It is true that 0.2.4 and 0.2.5j had a castling bug. In positions where the queenside rook starts on b1/b8, they would generate illegal castling moves when there was an enemy rook or queen on a1/a8. This is fixed in newer (not yet public) development versions. I have played (literally) thousands of test games with these post-bugfix versions, and there has not been any crashes or illegal moves. It would surprise me if there are any castling bugs left in my program.

I am sorry, that SMIRF will not be participating there, though being full Chess960 aware (and much more), because of the compatible X-FEN no longer is the officially recommended way to encode Chess960 games and positions, thus opening the door for serious incompatibilities.

I have tried to stay away from the discussions about Chess960 FENs, and I do not intend to start discussing this topic now either. Let me just say that from my point of view, there is still no standards for encoding Chess960 games and positions, but the level of interest in Chess960 among chess programmers is beginning to reach a level where it seems realistic to establish such standards soon. How these emerging standards will look is not quite clear yet, but the probability that they will resemble your preferences does not improve when you decide not to participate and meet the other programmers in Mainz.

I still hope you'll change your mind, and that we'll meet in Mainz next week.

Tord

[Reinhard Scharnagl]

Hi Tord,

no, I will not be in Mainz this event 2005.

And I will not try to start a discussion on the FEN. But before Shredder entered the FRC scene, there has been a compatible world of applications, PGN viewers, online servers and game data bases. Why change a winning team? So let stop here with this.

Reinhard.

X-FEN: http://www.chessbox.de/xfen_e.html

[Sven Schüle]

Hi Reinhard,

what do you think is the reason for common programs and interfaces of the computer chess world being incompatible to SMIRF?

As far as I know there have not been many tournaments where SMIRF had the chance to participate, at least not for traditional chess, but probably also for Chess960 (former FRC). Why? Are all the others not interested in playing games against SMIRF?

(OT here of course, sorry Tord!)

Sven

[Reinhard Scharnagl]

Sven,

Smirf is absolutely uninteresting in that (to be avoided) discussion. It is related to the FEN encoding of Chess960 positions. The majority of used FRC FENs are the starting positions of the 960 FRC initial arrays inside of PGN file entries. Therefore it is important, to keep especially those 960 FEN strings compatible and unique. Shredder ignores the existing of already Chess960 aware online servers, PGN viewers, databases, tools, GUIs and engines and has created an own "FEN" incompatibly encoding FRC starting positions, moreover creating TWO DIFFERENT STRINGS depending of Shredder's internal view. That is the problem, not e.g. Smirf.

Reinhard.