Author: Uri Blass
Date: 06:42:55 07/27/05
Go up one level in this thread
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.01 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.