From: Tord Romstad gmail com> Date: 30 jan 2007 Subject: Re: First draft of the Universal Shogi Interface (USI) ------=_Part_13757_4904633.1170163363968 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Manabu! > I still wonder if the proposed USI can adopt the method of notation (piece > names and squares etc..,) used in CSA standard kifu format rather than > described as SFEN even if USI and CSA protocol have different purposes. > I guess most of Japanese shogi programmers already got used to the > CSA method since WCSC hosted by CSA has 16 year history. Yes, I already suggested to switch to kifu notation for moves earlier in this thread, and if you think most Japanese programmers would prefer this, I will change it in the draft of my protocol. For me, it has no importance how moves are written, as long as they are easy to read and write for computer programs. The kifu notation is just as good as the one I suggested. I am a bit more reluctant to use the kifu notation for shogi positions, because it uses multiple lines to encode a single position. I want to be able to send a position and a complete move list to the engine with a single, one-line command. My original SFEN proposal no longer seems appropriate if we decide to use the kifu notation for piece names, but I am not sure what we should use instead. Here are two possibilities: 1. Use something similar to my SFEN proposal, but with kifu notation for pieces instead of the English piece letters. 2. Use the kifu notation for positions, but with all newlines replaced by some other character (perhaps '/'). The first of these have the advantage of being more compact, while the second would perhaps be slightly easier to implement in programs which can already read the kifu position notation. I have a slight preference for the first solution, but both are OK to me. > Several other inputs came to my blog after traslating your draft into > Japanese. > > The usage of Shogi software includes not only playing a game but > also solving tsume problems or finding if there are mates in a > specific position. It does not seem that your draft has defined how > to send back information whether there are mates or not from Engine > to GUI. This might be added. If you look closely, this information is already there. Look in section 5.3, under the command "info". The engine can give numeric scores by sending commands like "info score cp 139", or mate scores by sending commands like "info score mate 7" (if the program is winning) or "info score mate -6" (if the program is losing). > In section 3, the draft says > > "Again we use uppercase letters for black pieces, and lowercase > letters for white's captured pieces." "black pieces" should be > corrected as "black's captured pieces". You are right - thanks for the correction. Tord --^---------------------------------------------------------------- This email was sent to: shogi-l shogi net EASY UNSUBSCRIBE click here: http://topica.com/u/?a2i6Ys.aBVYf3.c2hvZ2kt Or send an email to: shogi-unsubscribe topica com For Topica's complete suite of email marketing solutions visit: http://www.topica.com/?p=TEXFOOTER --^---------------------------------------------------------------- ------=_Part_13757_4904633.1170163363968 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Manabu!

> I still wonder if the proposed USI can adopt the method of notation (piece
> names and squares etc..,) used in CSA standard kifu format rather than
> described as SFEN even if USI and CSA protocol have different purposes.
> I guess most of Japanese shogi programmers already got used to the
> CSA method since WCSC hosted by CSA has 16 year history.

Yes, I already suggested to switch to kifu notation for moves earlier
in this thread, and if you think most Japanese programmers would
prefer this, I will change it in the draft of my protocol.  For me, it
has no importance how moves are written, as long as they are easy to
read and write for computer programs.  The kifu notation is just as
good as the one I suggested.

I am a bit more reluctant to use the kifu notation for shogi
positions, because it uses multiple lines to encode a single
position.  I want to be able to send a position and a complete move
list to the engine with a single, one-line command.  My original SFEN
proposal no longer seems appropriate if we decide to use the kifu
notation for piece names, but I am not sure what we should use
instead.  Here are two possibilities:

1. Use something similar to my SFEN proposal, but with kifu notation
   for pieces instead of the English piece letters.

2. Use the kifu notation for positions, but with all newlines replaced
   by some other character (perhaps '/').

The first of these have the advantage of being more compact, while the
second would perhaps be slightly easier to implement in programs which
can already read the kifu position notation.  I have a slight
preference for the first solution, but both are OK to me.

> Several other inputs came to my blog after traslating your draft into
> Japanese.
>
> The usage of Shogi software includes not only playing a game but
> also solving tsume problems or finding if there are mates in a
> specific position. It does not seem that your draft has defined how
> to send back information whether there are mates or not from Engine
> to GUI. This might be added.

If you look closely, this information is already there.  Look in
section 5.3, under the command "info".  The engine can give numeric
scores by sending commands like "info score cp 139", or mate scores by
sending commands like "info score mate 7" (if the program is winning)
or "info score mate -6" (if the program is losing).

> In section 3, the draft says
>
> "Again we use uppercase letters for black pieces, and lowercase
> letters for white's captured pieces."  "black pieces" should be
> corrected as "black's captured pieces".

You are right - thanks for the correction. 

Tord

------=_Part_13757_4904633.1170163363968--