Author: Reinhard Scharnagl
Date: 00:44:06 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. > >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). I have had an additional idea. May be it is completely unnecessary to provide constant options like 'FRC' or '10x8'. The GUI initially could try to send some typical FEN strings to the involved engines. When receiving an '0000' as bestmove the GUI should know, that the appropriate engine is not aware to handle that subvariant. Maybe it would be better to send back simply an 'illegal' than a nullmove as bestmove. 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.