Author: Reinhard Scharnagl
Date: 06:59:02 07/27/05
Go up one level in this thread
On July 27, 2005 at 09:42:55, Uri Blass wrote: >On July 27, 2005 at 03:42:05, Reinhard Scharnagl wrote: > >>On July 27, 2005 at 02:30:34, Alessandro Scotti wrote: >> >>>On July 27, 2005 at 01:05:33, Reinhard Scharnagl wrote: >>> >>>>SMIRF though using TMCI is showing by doing that it is possible to support a lot >>>>of variants WITHOUT SWITCHING the engine's mode simply by communicating with >>>>compatible FEN strings and encoded moves. This idea also could have been >>>>applicated to a UCI protocol extension. But actually that switches an engine >>>>into an FRC mode forcing the engine to different encoding of moves and FEN >>>>strings, e.g. generating different FENs for identic positions (where castling >>>>rights are based on traditional K+R placements only). >> >>Hi Allessandro, >> >>>I would not say that engine is "switched into FRC mode". Communication protocol >>>and engine interface should be completely separated, although they usually >>>aren't for practical reasons. Also, why not telling the engine it's going to >>>play FRC? Having more information at hand is rarely going to hurt, and you can >>>always throw it away. >> >>the problem is not the switching itself. But it is used to 'prove' Chess960 to >>be an incompatible variant. All information needed is already included in to be >>communicated FEN strings. >> >>And if you like to switch (for which obscure purpose ever) there is no need to >>change the enconding of transferred moves. My proposal (and the way Smirf works) >>is to encode castlings as kings moves when having at least two elementary steps >>and as move to the involve rook otherwise. This constitutes a compatible way >>along traditional chess, avoids misunderstandings looking at King's single step >>moves, and it establishes clear gestures to be made at a GUI to enter any >>castling move. >> >>And of course it is counter productive to change the way of producing a FEN >>string. Shredders approach now would produce different FEN strings in positions, >>where existing castling rights are related to traditional K+R placements. This >>does not make any sense at all. >> >>But as a rule to avoid switching FORCES COMPATIBILITY instead of such nonsense. >> >>>A protocol adaptor, which you would have to write for TMCI anyway, can easily >>>translate FEN and adjust castling moves before passing them to the engine if >>>needed. >> >>Because TMCI is rather modern this would not work in both directions. And as >>long as extended UCI will mutually make Chess960 an incompatible variant, there >>is no way to give me any motivation for to do this. >> >>>P.S. I really like SMIRF and your ideas on chess programming, so I hope >>>development may restart soon! >> >>I just have published the status quo to enable chess programmers to watch a >>working compatible Chess960 concept beside of protocol questions. >> >>But when the situation is not changing (e.g. by the Chess960 WNCA to publish >>quality concepts for Chess960 representations in FEN, PGN and GUI gestures) I >>will work on other ideas like Go programming etc.. >> >>Reinhard. > >It is your decision but I do not understand how notation disagreement(of things >like how to encode castling) can convince people not to work on chess960. > >As far as I understand there is already a tool to translate Shredder's notation >to your notation and the opposite(see >http://www.volker-pittlik.name/wbforum/viewtopic.php?t=3135). > >I see no reason that protocol will not allow every program to choose between >X-Fen and Shredder's Fen in the same way that arena allows both UCI engines and >winboard engines to play inside it inspite of the fact that they are using a >different protocol. > >Uri
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.