Author: Michael Yee
Date: 02:54:31 03/13/05
Go up one level in this thread
On March 13, 2005 at 03:23:57, Reinhard Scharnagl wrote: >On March 12, 2005 at 21:36:31, Reinhard Scharnagl wrote: > >>On March 12, 2005 at 21:08:58, Michael Yee wrote: >> >>>... >>>You can view the proposed protocol here: >>> >>>http://web.mit.edu/myee/www/chess/xci1.html >> >>Hi Michael, >> >>I will have a look on it. Actually it is aready late here. >>... > >Well Michael, I have had a look on it. > >A) to define a new protocol has chances to simplify the nature of a GUI, which > then could be build easier and faster. Moreover it would be much easier to > include more variants, when transferring the knowledge and creation of valid > moves to an engine (may be a verified one, assisting as referee when the GUI > is moderating between two engines or an engine and a local player). Of course > that referee engine also could be chosen from the engines involved as long > as no "valid" referee engine has been verified. The GUI simply has to handle > the affected coordinats with exception of e.p. and castling moves (if not > been split into artificial pseudo moves). > > There should be an ability to request all valid moves when an engine is in > WAIT/READY state. That will do the whole referee task. > That's an interesting idea. So if a new variant suddenly materialized (that still fit within the framework of the protocol--e.g., not something like bughouse?), the GUI wouldn't have to be changed. I guess the engine would also have to detect end of game in this case. Maybe the protocol can allow both ways, in order to let the GUI be the established referee for standard variants, while letting newer (or less popular) variants still be supported. New commands from GUI to engine could be: getmovelist getresult >B) To your point 8: Encoding your castling would not work. There is only a need > to distinguish castling moves from simple king's moves or technical null > moves. Thus it is sufficient to mark castling moves when the king is not > making at least two elementary steps. An appended symbol could be selected > as a marker, maybe 'c' for 'castling' or 'k' for 'king'. But using a 'c' > would be problematic because that suffix also would happen in promotions > on a 10x8 Capablanca board, when chosing a chancellor. Thus I recommend 'k', > which is not used elsewhere as suffix. > Good point. I had seen your "k" suggestion before, but didn't catch the reason. >C) To your point 5: please describe the detailed meaning of the states. It is > not clear to me, what differs THINK from ANALYSE. > THINK means the engine is computing with the goal of sending a bestmove eventually. This will happen during games. ANALYZE means the engine is computing with the goal of just sending thinking lines. It's triggered with the "go infinite" command. It can happen during a game (it in effect puts the current game on hold), but wouldn't make much sense there. The main reason for having the separate kind of thinking is that then the engine can send an "info book" line followed by thinking lines. And the engine has the option of having a different kind of analysis thinking if it wants (e.g., symmetric eval vs asymmetric). >D) To your point 7.x option: There seems to be the same mistake like in the > winboard protocol. One has to distinguish between variants and modes. It > does not make sense to distinguish 'normal', 'nocastle' and 'fischerandom' > as variants. They all belong to the variant 'chess'. It is the duty of the > GUI to provide a starting FEN string, which is acceptable by all involved > engines. Thus the engines have to signal to the GUI their awarness to some > special modes like FRC. This could easyly be done by the engines providing > a constant option. Thus option 'FRC' would signal that the engine also is > accepting nonstandard castling rights. An option '10x8' could signal, that > the engine also could handle FEN strings based on Capablancas 10x8 piece > set. > > The GUI has to check such options of the involved engines. It could offer > to start a new FRC game only, if all involved engines would have sent an > existing option 'FRC'. A comparable procedure has to be done before offering > a 10x8 Capablanca game. CRC is possible only, if both options would exist > in all involved engines. > I'm pretty sure the XCI_Variant option works the way you're requesting. The engine might send option name XCI_Variant type combo var Standard var CRC during initialization, which would mean the engine supports these two variants. Then if the user requested a CRC game, the GUI would send setoption name XCI_Variant var CRC and any resulting position and move commands would be CRC type. I think this mechanism achieves what you said, but not necessarily in the same way. >E) To your point 7.x info: 'hashfull' is not to be understood. There never is > an empty place in RAM, but always filled with matching or unmatching data. > It might be more interesting how the chances are to find matching data. Smirf > e.g. is not making the cache 'empty' but marking entries as replaceable. > Thus it would be possible to find matching data in the transposition table, > even filled with old data from prior calculations, because replacable data > nevertheless could be valid to be reused. Thus a TT used that way never > would be empty once having done a calculation. > This is borrowed exactly from UCI. However, you could send something like: info name hashmatched description matched space in hash table during initialization. Then the engine could add that information to its thinking lines (and the GUI would be able to recognize it as a valid item of information) >F) Because not all engines involved might be working 100% correct, it would > make sense that an engine could signal to the GUI that it is regarding > itself in an illegal situation: e.g. receiving an illegal FEN string or a > move it could not execute. It would help to send a nullmove (encoded as > '0000') back to the GUI as bestmove. The GUI will have no other chances to > handle this, than doing the same as when the engine had resigned. But it > could display a message, that the resigning engine is regarding itself as > mistreaten. This would give the chances to investigate the source of that > error, may be located in the GUI or an involved engine (may be the referee > is an errornous and still unverified engine). > This is a good point that I was having a hard time coming up with a good solution for. I considered an "error" command from the engine to GUI that would put the engine back in the WAIT state (since it effectively would be saying it can't continue in the current game). I like your suggestion that the GUI could disply the engine's reason for "crashing," giving the engine a way to defend itself. The main reason I had decided against it previously is that if the GUI is 100% correct, there's no way for the engine to receive something incorrect. This implies that the engine would always be wrong and thus effectively resigned. >Regards, Reinhard. Thanks so much for your feedback, Reinhard. Much of the variant support is from your suggestions, so I'm very thankful. Michael
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.