Author: Reinhard Scharnagl
Date: 00:23:57 03/13/05
Go up one level in this thread
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. 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. C) To your point 5: please describe the detailed meaning of the states. It is not clear to me, what differs THINK from ANALYSE. 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. 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. 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). 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.