(本エントリーは、Tord Romstad 氏によるThe Universal Shogi Interface, draft 1
(2007-01-24) の ”4. Differences between the UCI and USI protocols” のTakodori による日本語訳である)
(gg さんのコメントを参考にし、一部修正しました。 2007/1/30)
(
4. UCIとUSIの違い
This section is intended for programmers who are already familiar with the UCI protocol. Those who do not know anything about UCI are adviced to skip to section 5.
本セクションは、UCIプロトコルに既になじんでいるプログラマー向けに意図されたものである。UCI については知識がないという 何も知らない方はセクション5にスキップされたい。
The USI protocol is identical to the USI protocol apart from the following changes:
USI プロトコルは、以下に述べる変更点を除いて、USI と同等同一である。
* An UCI engine consists of only the executable file, but an USI engine should contain a separate "translation file", a Unicode text file containing translations of the engine and author names and all the parameter names into one or more languages. The format for the translation file is not yet decided.
* UCI エンジンは、実行形式のファイルだけから成る。しかし、USI エンジンは、別途「翻訳ファイル」を持つことになる。これは、エンジンおよび開発者の名前、すべてのパラメーターの名称をひとつないしそれ以上の言語に翻訳したものを収納している Unicode のテキストファイルである。翻訳ファイルのフォーマットは未定である。* Spaces are not allowed in option names. This fixes a small defect in the UCI protocol: In a UCI chess engine, there are certain words (most notably "type") which cannot be used in option names because it would cause ambiguity. The only advantage of allowing spaces in option names is that it makes the names look cosmetically nicer in the GUI, and this advantage disappears in USI because the GUI will not display the option name, but the translation found for this option name in the translation file. For instance, if the engine has an option named "NULL_MOVE_R", the translation file can contain an English translation like "Null move reduction factor", and it is this translation that will be displayed in the GUI (assuming that the user has set English as her preferred language).
* オプション名称の中には、スペースを使うことはできない。これは、UCI プロトコルのある小さな欠点を手直しするものである。UCI を用いるチェスエンジンにおいては、あいまいさが生じるため、ある種の言葉は選択できる名称オプション名として使用できない("type"が最もよく知られている例)。オプション名称中ににスペースを使える様にする唯一の利点は、そうすることで GUI の見映えが良くなることだけである。そして、その利点は USI においては消滅する。というのは、GUI は選択可能な名称を表示するのではなく、「翻訳ファイル」中にある、オp所ンオプション名称に対応した翻訳された言葉を表示するからである。例をあげよう。仮にエンジンが"NULL_MOVE_R"というオプション名称をもっていたとすると、「翻訳ファイル」は、"Null move reduction factor" のような英語の訳語を持つことになり、まさしくその訳語が GUI 上に表示されることになる(これは、ユーザーが英語を好みの言語として設定したという前提での話である)* A new option type, "filename", has been added. This is identical to the "string" option type, except for the way it is presented in the GUI. For "filename" options, the GUI will display a file browser, while for "string" options, it will let the user type a string. The new option type is intended to be used for selecting opening book files and similar tasks.
* "filename"というオプションタイプが追加されている。これは、"string"というオプションタイプと、GUI で表示のしかた以外の点で同等である同一である。"filename"オプション用に、GUI は、ファイルのブラウザを表示する。一方、"string"オプションの場合には、ユーザーがstring文字列をタイプできるようになる。この新しいオプションタイプは、棋譜ファイルを開いたり定跡ファイルを選んだり、似たようなタスクを行ったりするのに使われるように意図されてしている。* Instead of FEN strings, SFEN strings (as described in section 3) are used. Where UCI uses position fen <fen>, USI uses position sfen <sfen>.
*(セクション3で述べたように)FEN string のかわりに、SFEN string(セクション3で記述)が使われる。すなわち、UCI が"position fen <fen>"を用いるところで、USI は"position sfen <sfen>"を用いるのである。* Moves are written in coordinate notation, using the standard English shogi coordinates with the upper right corner (white's left corner) as square 1a and the lower left corner (black's left corner) as square 9i. Normal moves are written exactly as in UCI, except for the different coordinates (e.g. 7g7f). Promotions are written with an extra '+' character at the end of the move (e.g. 4e3c+). Drops are written as a piece letter in upper case, followed by a star ('*'), and the destination square (e.g. P*3d).
* 着手は、座標記法で書かれる。右上の隅(白側の左隅)が1aという升目になり、左下の隅(黒側の左隅)が 9i という升目になる英語による標準的な将棋座標を使うことになります。使って書かれる。通常の指し手は、異なる座標表現(例、7g7f)を除いて、UCI と全く同様に書かれる。成りは、指し手の最後に '+'キャラクターを付加して書かれる(例、4e3c+)。持ち駒を打つのは、大文字の駒の一文字の後に、星印'*'と目的の駒を打つ升目をつける続けることによって書かれる(例, P*3d).* Mate scores are always sent using the shogi convention for move counting: We count plies, not full moves. Where you would send info score mate 3 in a UCI engine, you should send info score mate 5 in a USI engine.
* 詰みの記録は、常に将棋式の手数の数え方を用いて送信される。チェス式ではPlies を数え、すべての動きを数えないfull move ではなくply を数える。UCI エンジンにおいて3手詰め記録情報を送信するとき、USI エンジンでは、5手詰みの記録情報を送信しなければならない。UCIエンジンが3手で詰んだというスコアを送信するような場合は、USIエンジンは5手で詰んだと送信しなければならない。* All options with fixed semantics start with the prefix USI_. For instance, the option which is named Hash in UCI is named USI_Hash in USI.
*一定のプログラム動作を伴うその意味が決まっているあらゆるオプション名称は、接頭子 USI_ で始まる。例えば、UCI において Hash と命名されているオプションは、USI においては USI_Hash と命名される。
>プログラマー向けに意図されたものである
「プログラマーを意図したものである」あるいは「プログラマー向けである」
>UCI については知識がないという方
直訳「UCI について何も知らない方」ではダメ? 原著は「何も」を強調している様に思えるので.
>USI と同等である
原著のミスでUCIですよね.あと,identical は同等より強い意味なので
「UCIと同一である」or「UCIと全く同じである」が良いかと.
>持つことになる
shouldをどう訳すかなんですが,「持たねばならない」は(これでも問題はないんですが)ちょっと強すぎる感じなんで,「持つ」と言い切って誤魔化すのはどうでしょう?
>Unicode のテキストファイルである。
この後に「翻訳ファイルのフォーマット(or書式?)は未定である」が抜けてます.
>オプション名称には
「オプションの名称の中には」or「オプション名の中には」ですね.
>選択できる名称
「オプション名」ですよね?
#余計なお世話とは思いますが,オプション名称って日本語として座りが悪い様に感じます.名称が余り馴染みがない言葉だからでしょうか...オプション名,オプションの名前辺りが順当なような.
>オプション名称にスペースを使える
オプション名称中にスペースを使える
>GUI は選択可能な名称を表示するのではなく
GUI はオプション名称を表示するのではなく
>オp所ン名称
オプション名称
>GUI で表示しかた以外の点で
「GUI での表示法以外の点で」かな
>同等である
同じであるor同一である
>棋譜ファイル
これは「(序盤)定跡ファイル」では?
>使われるように意図されている。
受け身が重なるのはちょっとあれなんで,「使われることを意図している」
#ここのstringは「文字列」と訳してしまった方がいいと思います.
>SFEN string(セクション3で記述)
(セクション3で述べた様に)SFEN string
>Where UCI uses position fen , USI uses position sfen
UCI がfenである局面にを用いるところで、USI はsfenである局面にを用いるor
UCI が局面fenにを用いるところで、USI は局面sfenにを用いる
という意味に違いないと思うんですが,useにこういう使い方があると聞いたことがない...
>着手は、座標記法で書かれる。右上の隅(白側の左隅)が1aという升目になり、左下の隅(黒側の左隅)が 9i という升目になる英語による標準的な将棋座標を使うことになります。
普通に,
着手は、右上の隅(白側の左隅)が1aという升目になり、左下の隅(黒側の左隅)が 9i という升目になる英語で標準的な将棋座標を使った座標記法で書かれる。
ではいけないのでしょうか? 座標が重なるのが気持ち悪ければ「使った記法で」とすればいいと思いますが.
#後,ここだけ「ます」は妙です.
>異なる座標表現(例、7g7f)
異なる座標(例、7g7f)
>持ち駒を打つのは
持ち駒を打つ手は
>目的の升目
いい訳が見つかりませんが「打つ升目」あるいは「置く升目」でどうでしょう?
>升目をつける
升目を続ける?
>Plies
ply(Pを大文字にする理由がないのと日本語では通常単数形を用いるので)
>チェス式では Plies を数え、すべての動きを数えない
Full moveではなくplyを数える
#チェス式ってのはどこから?
>UCI エンジンにおいて3手詰め記録情報を送信するとき、USI エンジンでは、5手詰みの記録情報を送信しなければならない。
UCI エンジンが3手で詰んだというスコアを送信するような<仮定法なので>場合は、USI エンジンは5手で詰んだと送信しなければならない。
#スコアを「記録」と訳してしまうのはちょっと無理がある感じなのでスコアのままにしました.
>一定のプログラム動作を伴う
そのまま「その意味が決まっている」だと思いますが?
今日は時間が無くなったのでここまでにします.もしモンテカルロ碁に興味があったら上のURLにある論文の和訳も宜しく (_ _).
投稿情報: gg | 2007年1 月28日 (日) 00:44
> gg さん 時間をかけてチェックしていただきありがとうございます。
参考にし、ほぼお説の通りなおしました。
一点、「(序盤)定跡ファイル」なんですが、私の知識の無さに起因するのですが、チェスの場合、定跡ファイルという終局までのデータを持たない形の「定跡」ファイルを持っているのか、そうではなく終局までのデータを持っていてそれを参照しているのかちょっとわからなかったので、そのままといたします。
投稿情報: takodori | 2007年1 月30日 (火) 18:58
チェスは私も全く知りませんが,それならなおのことopening book fileを直訳して序盤定跡ファイルとするのがベターだと思います.
#囲碁ではopening bookは(序盤は冗長なので略して)定石と訳されます.
##チェスにはclosing book(終盤定跡)ってのもあるんでしょうかねぇ?
翻訳というのは地味ですが物凄く大切なことだと思います(欧米ではプロトコルの策定やマニュアルの整備,対局サーバの運用の様な,環境を整える作業もきちんと評価されるんですが).頑張って下さい.
投稿情報: gg | 2007年2 月 1日 (木) 10:59
> gg さん。
今よく読み直すと、selectingを読み飛ばして、文法的に誤読していたのに気づきました。おっしゃるとおり、ここは明快に「定跡ファイル」とすべきでした。そのように直します。
投稿情報: takodori | 2007年2 月12日 (月) 23:52