Author: Reinhard Scharnagl
Date: 16:13:06 06/13/04
Go up one level in this thread
On June 13, 2004 at 18:17:29, Sune Fischer wrote: >On June 13, 2004 at 17:44:17, Reinhard Scharnagl wrote: > >>Well I do not know, whether it would help to explain those points here, >>but it is a fact, that UCI and Winboard handle FRC very different. And its >>only up to flexible GUIs like Arena today to cover such weaknesses. >> >>1) Winboard does not support FEN position strings for all WBx versions, >> but both (WB and UCI) have to support extended FRC-FEN to be fully FRC >> aware, because there FRC positions exist, not expressable in normal FEN. >>2) Winboard handles FRC as a variant, which it is not at all. It is a >> compatible upper set of chess. Having supported FRC-FEN strings, there >> would be no need to distingush between 'normal', 'fischerandom' and >> 'nocastle'. The engine simply has to signal to the GUI its FRC awareness, >> what could be done easyly in UCI. The GUI then is deciding, whether the >> involved engines would play FRC and then support a appropriate starting >> position as FEN string. >In winboard's case I think it's okay to handle FRC as a variant feature. > >All these features indicate something outside or above the minimum requirement. >For a chess engine the minimum requirement is knowing the rules of chess, to >also know the rules of FRC is an additional "feature", in some sence. a) a none FRC aware engine has no need to care about such things like FRC. b) a FRC aware engine has no need to distinguish between those 'variants'. So what? >The word variant may not be entirely accurate, but I think that's a bit of an >academic debate. No, it is not academic, because that (from the view point of a FRC engine) unnecessary distinction causes different castling encodings (following the Winboard specifica for 'fischerandom'). This dualism is 'academic' nonsense. >>3) a FRC aware engine is always playing FRC, there is not need to switch >> between any modes. >>4) in Winboard there is a formal inconsistence concerning the encoding of >> castlings. Because of the inherent identification of all possible FEN >> positions it makes no sense to demand a different encoding of castlings >> in those 'variants' as specified for 'fischerandom'. UCI has a lack of >> specification in that case but also no contradiction. >> >>A possible solution to that dilemma is descripted at a page of my site, and >>in slightly different form implemented within the Arena GUI. >>[http://www.chessbox.de/Compu/fullchess5b_e.html] >Regarding your page on the UCI implementation, is this officially part of the >UCI? There are two components: a) the options: why should there be a problem. There is no thinkable conflict. Arena seems to handle it that way. It does not hurt any UCI laws. b) the castling encoding: only the very short castlings have to be encoded in a different way, for not to be mixed up with null-moves or regular moves of the king. Appending 'k' seems to be natural as in promotions. But the engine should always accept alternatives as O-O-O. The behaviour should be choosable by another option, because that is a GUI problem to translate between diffe- rent engines, e.g. between UCI and Winboard. Both proposals has been brought to the inventor of UCI, but still have not become part of a standard. I don't know why. I hope it will be also included. He wrote in a posting, that this would work compatibly. But obviously he had not seen a need to support FRC by putting this into the UCI definition. May be he wants to see first a well working such engine with that protocol. >I'm also wondering what the reason might be for using a combo box instead of a >check box, as used for "Ponder"? As I told, there is no need for a FRC engine to deny that ability. Or why? Therefore a checkable option or one with alternatives is suggesting nonsense. Indeed the GUI simply has to check the existence of that option, not its nature. >shine on, >-S. Regards, Reinhard.
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.