新しい棋譜形式について
ginsho
JSON棋譜形式そのものに関する議論と、JSON棋譜を扱う側の議論は後々分けた方が
見通しがよくなる気がしますが、とりあえずは既存棋譜形式の問題点について重箱の隅突きを
しつつ、na2hiroさんがJSON棋譜のアウトラインを固めやすくなるようなネタを出していく方向で
すすめてみるのはどうでしょう。
＞na2hiroさん
デファクトスタンダードであるKIF棋譜が、JSON棋譜の場合こう記述されますよ、的ビフォーアフター
比較があると皆で議論を膨らませやすい気がするんですが、お願いできませんでしょうか？
＞fantakeshiさん
以前ツイッタでSFENの拡張についてちょっとだけ話したことがあったと思うんですが、JSON棋譜の
恩恵にあずかる形でそれができそうな気がしてます。この辺もつついてみませんか？
na2hiro
例えば直訳するとこのような感じになります(長いので別ページ)
http://pastebin.com/kNg789qf
元のKIFと，それをJSONに直したときの例です．
もっとも，今のままでは不便な所があります．
例えば，
・連想配列のキーが日本語なので，プログラムで利用する時にobj["対局ID"]のように日本語で書かなければならないので，英単語などに置き換える
・消費時間やリーグ成績は先手と後手に属する情報にしたほうが良さそう
→たとえば
"players": [
{
"name": "広瀬章人",
"result": {"win": 3, "lose": 3},
"time": 479
},
{
同様に後手
}
]
のようにする等．これだとプレイヤーの属性について，例えば段やタイトルの情報も付け加える事が出来ます．
・駒取りの時，取った駒の情報を入れないと，手順の逆再生時に困るか？
・成も成る前の駒情報を入れる？
ちなみに，今考えているのは，会合のほうでも少しお話ししましたが，設定ファイルを分離して持つものです．
ルール(本将棋，どうぶつしょうぎ，・・・)ごとにルール情報ファイルを決めておきます．
棋譜自体のほうには，どのルールの棋譜なのか，rule: "shogi.rule.json"などと書いておくようにします．
こうすることで，新しいルールへの対応が非常に簡単になります．
例えば大将棋の棋譜を手に入れたが，自分が普段使っているソフトでは対応してなかったとします．
ソフトはファイルのrule部分を見て，「"daishogi.rule.json"には対応していません」と文句を言います．
そんな時，daishogi.rule.jsonというファイルをググってきて誰かが公開した(規格の公式サイトに
置けるようにしているなら，そこからでも)ダウンロードしてきて，自分のソフトのrulesディレクトリに
保存すれば，もうこのソフトは何のルールでどんな駒があるのかを理解できるというわけです．
もちろん，大将棋も対応するとなったら，9x9より大きくてもインターフェイスが
変にならないように気を使う必要がありますが，まあ嫌ならルールファイルに書いてあるサイズを見た後に
「盤面がでかすぎるのでダメです」とか言えばいいでしょう．
そのルールファイルの例です．
駒の表記(伝統形式，PSNのようなチェスライク形式)も切り替えられるように，
traditionalとchesslikeの2つの情報が入っています．kanaというのを増やして"fu" "kyo"のようにできてもいいかもしれません．
shogi.rule.json:
{
size: [9, 9], //9かける9
species: {
traditional: {
"0": "歩",
"1": "香",
～～～中略～～～
},
chesslike: {
"0": "P",
"1": "L",
～～～中略～～～
}
},
initial: { //初期情報
"ban": [ //初期局面
{player: 1, species: 1}, {player: 1, species, 2}, ～～～//香,桂
～～～
]
}
}
doubutsushogi.rule.json
{
size: [3, 4],
species: {
traditional: {
"0": "ひよこ",
"1": "きりん",
"2": "ぞう",
"3": "ライオン",
"4": "にわとり",
},
english: {
"0": "baby bird",
～～～
}
},
"init": {
～～～
}
}
init.banのところでさらりと盤面の表記をしてしまいましたが，1マスを
{player: 1, species: 2}
で表すのは冗長なので，
[1, 2]
のように「0番目はplayerで1番目は種類だよ」と確約しておいてもいいかもしれません(将棋ったーではそうしています)
まあ，おおざっぱにはこんなところです．
2011年9月15日0:39 ginsho <kzde...@gmail.com>:
> --
> ginsho会(仮) - http://groups.google.com/group/shogi-developers
>
--
na2hiro (http://81.la)
twitter: @na2hiro
ginsho
お忙しいところ詳しい説明をありがとうございました。
リンク先のサンプルでグッとイメージがわいてきました。
まず基本的なところの確認を。JSON棋譜は指し手ごとの局面情報は持ちますか？
記述としてはSFENの空きマス圧縮を展開したような形になると思うのですが。
指し手ごとに局面情報を持っていると、
・一手分のエントリーだけを記述して、詰問題に
・不連続で複数手のエントリーを記述して、詰問題「集」に
・連続する複数手のエントリーにコメントを付加して、正解手順、解説を付きの詰問題に
・対局から、注目すべき手のみをピックアップした、ダイジェスト棋譜（局面図集、みたいなもの）
といった具合に、JSON棋譜の記述ルールに従いつつ、様々なコンテンツが記述できるようになり
情報発信者にはうれしい形式になると思っています。
それからもうひとつ。棋譜とルール定義の分離で思いついたのですが、
これ、完全な指し手情報を持つ「親棋譜」と、任意の指し手に対する任意のパラメータしか持たない「子棋譜」
を用意し、組み合わせて利用することにも使えるでしょうか？
例えば、ライブ中継されている親棋譜に対して、棋譜ビューア側が
・コメントのみ記述された子棋譜をミックス表示して、多言語同時中継
・AIの形勢判断のみ記述された子棋譜をミックス表示して参照
・変化手順のみを記述された子棋譜をミックス表示して本筋と比較参照
みたいなことができると、なかなか楽しそうです。
こういったことは既存の棋譜形式だと、親棋譜のコピーをゲットして中身を書き換える作業が必要になるので
なかなか面倒です。情報発信までに時間がかかってしまいますし。
以上、単なる思いつきですが書いてみました。
Madoka Kitao
どうぶつしょうぎ=3x4将棋の棋譜ですが
「きりん +」「ぞう x」「らいおん o」「ひよこ '」「にわとり *」
を考えたのですが、これだとプログラムは書きにくいですか?
Kawasaki Tomohide
棋譜ファイルを使って何かソフトを作る側からの意見をいいますと，
「手」の情報のみから色々なことが分かる方が有難いです．
たとえば，英語の表記では
・単に▲5五角 → B-5e
・駒を取りながら▲5五角 → Bx5e
と変化します．
つまり駒を取る手かどうかの情報を「手」の中に入れてくれないと，
ただ英語表記にしたいだけなのに，いちいち前の局面を参照しないといけません．
(つまり初手から再生しないといけません)
日本語でも，「同」をつけるかどうかの判断には，1手前の参照が要りますね．これも面倒です．
CSA形式はその面でもっと不便で，その手が成りなのか，もとから成り駒だったのかすら，
前の局面を参照しないと分からないです．
※成った前と後の駒の種類を記録しておく件は，その必要があるかどうかよく分かりません．
ルールファイルに「歩⇔と」などの対応関係を定義してもよい気もします．
※ところで，本将棋とどうぶつしょうぎでルールファイルを分けるのは分かりましたが，
駒落ちも全て分けるのですか? (初期局面がそちらに入っていたので)
ルールファイルは統一して，初期局面と初手の手番のみ
棋譜ファイルの方に書いても良い気がします．
詰将棋などの場合もあるので，初期局面と手番を棋譜ファイルが保持できないようでは
使い道がせばまると思います．
北尾先生，
「きりん +」「ぞう x」「らいおん o」「ひよこ '」「にわとり *」
を考えたのですが、これだとプログラムは書きにくいですか?
プログラム上は全く問題ないと思いますが，
+は成り，xは取る，*は打つ，で使われているので，
それに慣れている人にとってとても読みづらいです．
あと，記号やアルファベットを混ぜてしまうと，それらの幅や高さ位置のばらつきが
フォントによって様々なので，ソフト開発者が表示にとても気を使わされることになります．
「'」などは，文字に挟まれるととても狭くなり，駒を表しているようには見えません．
せめて全角で統一した方が良いと思います．(＋ × ○ ・ ＊)
にわとりは「〒」とか「干」とか「甲」とかもあるかと思います．
ライオンは「※」でもいいかも．
na2hiro
> 記述としてはSFENの空きマス圧縮を展開したような形になると思うのですが。
>
> 指し手ごとに局面情報を持っていると、
> ・一手分のエントリーだけを記述して、詰問題に
> ・不連続で複数手のエントリーを記述して、詰問題「集」に
> ・連続する複数手のエントリーにコメントを付加して、正解手順、解説を付きの詰問題に
> ・対局から、注目すべき手のみをピックアップした、ダイジェスト棋譜（局面図集、みたいなもの）
1手ごとに局面を持つのは冗長すぎる気がします．指し手情報だけで順・逆方向の盤面再生ができれば
十分ではないかと思います．
Hidetchiさんの提案とも関係してきますが，この棋譜に初期の局面，持ち駒，手番を持てるようにしてから，
この棋譜形式自体を配列として持つ「棋譜集」形式のようなものを定義すればいいのではないかと思います．
具体的には，棋譜形式を
{
"init": {
"ban": [
初期配置
],
"mochigoma": [
初期持ち駒
],
"teban": 初期手番
},
"players":
～～～以下同様
}
のように開始時の盤面を持てるようにします．
そして，
{
"title": "1手詰め集", //棋譜集に関する情報
"author": "誰々",
"collection": [ //実際の棋譜集
{ //棋譜1
"init": {～},
～
},
{ //棋譜2
"init": {～},
},
～
]
}
という，棋譜を内包する「棋譜集」形式を使って，局面の集合を表すと良いのではないでしょうか．
これなら，それぞれの要素は普通の棋譜形式なので，棋譜やコメント，プレイヤー情報等を持たせる事も出来ます．
これで箇条書きであげられたそれぞれのものを表す事ができるのではないでしょうか．
> それからもうひとつ。棋譜とルール定義の分離で思いついたのですが、
> これ、完全な指し手情報を持つ「親棋譜」と、任意の指し手に対する任意のパラメータしか持たない「子棋譜」
> を用意し、組み合わせて利用することにも使えるでしょうか？
>
> 例えば、ライブ中継されている親棋譜に対して、棋譜ビューア側が
> ・コメントのみ記述された子棋譜をミックス表示して、多言語同時中継
> ・AIの形勢判断のみ記述された子棋譜をミックス表示して参照
> ・変化手順のみを記述された子棋譜をミックス表示して本筋と比較参照
継承とか上書きのようなものですね．面白そうです．
子棋譜中に override: "親棋譜ファイル名" と書いておき，子棋譜が読まれたらまず親棋譜を読み込んだ後に
上書きするような感じですか．ファイル側ではこれさえ書いておけば十分かと思います．
> どうぶつしょうぎ=3x4将棋の棋譜ですが
> 「きりん +」「ぞう x」「らいおん o」「ひよこ '」「にわとり *」
> を考えたのですが、これだとプログラムは書きにくいですか?
表示側の話なので，どんな記号でも問題ないと思います．
Hidetchiさんのおっしゃる通り，見た目がどうかという話になります．
> 棋譜ファイルを使って何かソフトを作る側からの意見をいいますと，
> 「手」の情報のみから色々なことが分かる方が有難いです．
> たとえば，英語の表記では
> ・単に▲5五角 → B-5e
> ・駒を取りながら▲5五角 → Bx5e
> と変化します．
> つまり駒を取る手かどうかの情報を「手」の中に入れてくれないと，
> ただ英語表記にしたいだけなのに，いちいち前の局面を参照しないといけません．
> (つまり初手から再生しないといけません)
> 日本語でも，「同」をつけるかどうかの判断には，1手前の参照が要りますね．これも面倒です．
> CSA形式はその面でもっと不便で，その手が成りなのか，もとから成り駒だったのかすら，
> 前の局面を参照しないと分からないです．
同意です．
・取った駒の種類を持つ
・成った時に分かるようにする
・「同」が曖昧なので元の座標も持つようにする
が必要ですね．
あと，
> ※成った前と後の駒の種類を記録しておく件は，その必要があるかどうかよく分かりません．
> ルールファイルに「歩⇔と」などの対応関係を定義してもよい気もします．
ですが，確かにそうですね．将棋ったーで100種類のルールを作ってきましたが，
駒の表裏の関係が崩れたことは一度もなかったので，表裏対応をルールファイルに書くのは良い案だと思います．
それなら，通常の移動情報に加えて成ったというフラグを1つ持たせるだけで良いですね．
ルールファイルに持たせる表記としては，例えば
0が歩, 9がと金となっていたとして，
"nari": {
"0": 9, //歩: と金
"1": 10, //香: 成香
～～～
}
というのがひとつの方法ですね．
> ※ところで，本将棋とどうぶつしょうぎでルールファイルを分けるのは分かりましたが，
> 駒落ちも全て分けるのですか? (初期局面がそちらに入っていたので)
> ルールファイルは統一して，初期局面と初手の手番のみ
> 棋譜ファイルの方に書いても良い気がします．
> 詰将棋などの場合もあるので，初期局面と手番を棋譜ファイルが保持できないようでは
> 使い道がせばまると思います．
初期局面を指定できるようにするのは作ったほうがいいと思いますが(上のほうでも書きましたが)，
駒落ちの棋譜ファイル全てに初期局面を指定する必要があるのはスマートではないと思います．
それに，もしルールで分けずに初期局面で分けるとなると，プログラムはそれが香落ちであっても
平手なのか香落ちなのか分かりません．といって，"teai": "香落ち"と棋譜に持たせようとするのは，
外国語環境向きでないので，何かの記号に置き換えればいいわけですが，それならいっそ
rule: "kyoochi.rule.json"を持てば良いのではないでしょうか．そしてルールファイルのほうで多言語の表記を
用意しておくわけです．
Kawasaki Tomohide
1手ごとに局面を持つのは冗長すぎる気がします．指し手情報だけで順・逆方向の盤面再生ができれば
十分ではないかと思います．
・「同」が曖昧なので元の座標も持つようにする
が必要ですね．
駒落ちの棋譜ファイル全てに初期局面を指定する必要があるのはスマートではないと思います．
それに，もしルールで分けずに初期局面で分けるとなると，プログラムはそれが香落ちであっても
平手なのか香落ちなのか分かりません．といって，"teai": "香落ち"と棋譜に持たせようとするのは，
外国語環境向きでないので，何かの記号に置き換えればいいわけですが，それならいっそ
rule: "kyoochi.rule.json"を持てば良いのではないでしょうか．そしてルールファイルのほうで多言語の表記を
用意しておくわけです．
ginsho
棋譜が指し手の局面情報を持っていると、数百、数千の棋譜ファイルから完全一致局面を探し出すために、棋譜データベースソフトを用意する必要もなくPC
のデスクトップ検索機能を利用すれば済む話になります。
部分一致局面が欲しいのであれば、正規表現検索に対応したマルチファイル検索を行うだけなので、たぶん秀丸かなにかがあれば充分でしょう。
さらに、指し手ごとの局面情報を含む棋譜形式が広く利用されることになれば、局面検索はローカルPCのデスクトップや棋譜データベース上だけでなく、そ
れを掲載するインターネット全体も検索対象となります。
例として、広大なインターネットから第51期王位戦第4局の103手目と同一の局面を持つ棋譜を探し出したい場合を考えます。
棋譜が局面情報を持っていれば、必要なのはその局面情報をそのままGoogleで検索することだけです。
今はまだそのような棋譜形式が存在しませんからSFENを代用しますが、検索文字列は以下のようになります（実際にググってみて下さい）
kn6+P/lsl6/pppG4p/9/3p1PBp1/2P1r4/PPSP4P/LSG1+l4/KNG1+p2N1
おそらく、どこぞのページが一つ引っかかったと思います。
検索者が「王位戦」という日本語を理解し読み書きすることも特別な将棋ソフトウェアを導入することも無く、一瞬で検索結果を手に入れられたことは強調し
ておきたいところです。これは棋譜が局面図情報を持つことのわかりやすいメリットと言えます。
棋譜が局面情報を持たないという選択はこのような高い検索性を捨てることになるのですが、ずいぶんもったいない話だと思いませんか？
たしかに冗長にはなりますが、逆に既存棋譜形式は冗長でないから不便だったのではないかと思っています。
Kawasaki Tomohide
棋譜が局面情報を持たないという選択はこのような高い検索性を捨てることになるのですが、ずいぶんもったいない話だと思いませんか？
na2hiro
> 局面を参照するのは面倒なのですが、1手前を見るぐらいなら簡単なので。
> それか、それぞれの手が、「自分の1つ前の手」(へのアドレス?)というメンバを持つべきなのかもしれません。
> というのは、分岐する棋譜の場合には、木構造と言うのでしょうか、親(1手前)と子(1手後)へのアドレスを持つような構造が望ましいですよね。
> KIF形式がどのように分岐を処理しているのか知りませんが・・
確かに同の座標はあってもなくてもいいですね．
JSONならパースの時点で内部的な(メモリ上の)構造になってしまうので，全ての手で前後へのポインタを
持つのはあまり冴えないと思いますが，分岐は擬似的にポインタのようなものが必要そうですね．
例えば
{
0: [ //メイン
{kifu: 1手目},
{kifu: 2手目},
{kifu: 3手目, bunki: [1]},//1番の分岐へ
{kifu: 4手目}
]
1: [ //1番の分岐
{kifu: 3手目2},
{kifu: 4手目2}
]
}
という感じです．
> 「同」よりも面倒なのが「上」とか「直」とかですが、これは1手前の局面を参照しなければいけないですよね。
> こういうのまで手の中で保持するのはさすがにスマートではないとなると、結局、前局面の生成は自分でやるしかないですか。。
同や上など，いちいち局面を生成しなくてはわからないけど人間が欲しい情報は，保存したいところですね．
> ところで、例えば次の1手のような問題図を表示したいとき、その局面を初期局面として棋譜ファイルを作った場合を考えますと、
> 図面の上には「○手目○○まで」という表示が要る場合があります。
> ということは、初期局面にも「前の手」や「○手目」などの情報が必要なのですね。
> それどころか「図は△2四同歩まで」などという場合もありますから、「同」を判断しようとすると、
> やはりフラグを立てるか、初期局面の2手前の手まで保持する必要が・・・
開始手数についてはinit配下にtesuu変数を用意すれば良いですね．
「△2四同歩まで」についてですが，最初に特に触れなかったのですが，慣例的に行われている「初期局面のコメント」
を実現するために指し手の0番目は指し手を書かずに初期コメントだけ書くようにしています．
たまたまですが，この0番目の位置に「△2四同歩」にあたる棋譜を書けばすっきり収まりそうです．
> 棋譜が指し手の局面情報を持つことのメリットを書いてみます。まず、高い検索性について。
なるほど．局面の一致検索を棋譜ファイルで行うのは気づきませんでした．確かにその用途となると便利ですね．
棋譜ベースではなく局面ベースのデータベースは@koudayuさんも着目されていますし，
(http://www.flatz.jp/archives/112 ※4年前) 自分も将棋ったーが一段落したら作ろうかと思っていました．
しかし，データベースに限らず，そこかしこに局面表記を埋め込んで検索でなんでも出てくるというのは
将棋界のユートピアかもしれませんね．全く知らないサイトでも，局面ハッシュの埋め込まれた棋譜さえ
張ってあれば，自分の探してる局面にすぐにたどり着ける訳ですね．
局面ハッシュは，少し前に局面データベースのために調べたので多少知っているのですが，
局面→ハッシュの単方向ならZobrist Hashingがコンピュータ将棋で使われる事が多いです．
http://yowaken.dip.jp/tdiary/20081001.html
予め11～99×歩～龍とでランダムなビット列を決めておき，動かすたびに局面の差分にあたるビット列を
局面ビット列に対しXORを取ります．76歩なら"77の歩"と"76の歩"にあたるビット列の2つをXORします．
どう経由しても同じ局面なら同じハッシュになり，その逆は，ハッシュ長で衝突を調整します．
1手ごとに数回XORするだけ非常に低コストかつ短いです．
この方法だと固定長で，多分やりやすい32bitsか64bitsでやることになると思います．
復元可能な圧縮としては，出現頻度を用いたハフマン符号化を行った方がいます．
http://www.geocities.co.jp/CollegeLife-Cafe/8331/shogi/index.html
可変長で，200bits程度だということです．
ちなみにWeb検索可能となると大文字小文字も区別できないので0-9a-zくらいでしょうか．
0-9a-vの32通りで5bitsを表せるので， バイト数=ビット数/5 程度の長さになりそうです．
前者なら7or13バイト，後者なら40バイト程度ですね．
自分は，横方向(ファイル間・サイト間)の一致検索さえできれば，あとはそれぞれの棋譜で縦(指し手)を辿れるので，
局面の逆算はそれほど必要ないのではないかと思いますが，何か逆算できたら嬉しい例などありますでしょうか．
na2hiro
2手というところを見過ごしていました．
1手前は0手目のところに入れ，"同"フラグと座標を書けば収まりそうですね．
takodori
私は、新しい棋譜形式が将棋というゲームの理解をより深めるというのにより貢献しやすくなるべきだと思っています。
その立場からすると。
(1)手の情報は多くもてるほうがよい
(2)局面の情報もあった方がよい。
ということになります。これからは、インターネットやPCで映像を使うのがごく当たり前の時代に
なるでしょうから、局面ごとのデータを持つのは、既存の手だけの情報に比べると冗長ですが、
映像データに比べれば問題にならないくだい軽いのでは、という見方もできるかと。
で、(1)と(2) について、もう少し詳しく書いてみます。
hidetchi
>「手」の情報のみから色々なことが分かる方が有難いです．
>たとえば，英語の表記では
>・単に▲5五角 → B-5e
>・駒を取りながら▲5五角 → Bx5e
>と変化します．
の情報を持っています。これらの情報があると、「平均的にみて総手数のなかで、駒を打つ割合はどのくらいか」
とか、「飛車と角ではどちらのほうが打って使う場合が多いか」「香車や桂馬は置き駒が活躍する将棋が多いのか
それとも持ち駒になって打たれて使われるほうが多いのか」などの統計的な解析が可能になるかなと思っていま
す。特に、将棋は他のチェス・将棋類と比べて、成れる駒が多い、持ち駒を使える、という点が際立った特徴です
ので、その特徴がゲームの面白さ、奥深さ、魅力になっているということをコンピュータによる解析で浮き彫りにで
きるようなデータの持ち方が理想です。
指した手が、「相手の駒を次に取れる手かどうか、その駒の種類」「次に成ることが可能になる手かどうか」を持っ
ていると、中終盤の手の解析がさらに進むと思っています。終盤で、どちらにも当てはまらない手は、仕方なく指して
いる手か、とんでもなくぼんやりした妙手の可能性が高いので、多くの棋譜のなかからぼんやりとした妙手の発見に
役立ちます。
局面のデータベースでは、「その局面が詰めろかどうか」「その局面ではどの駒が浮き駒か」「その局面ではどの
駒が相手のどの駒とアタリ（次に取ることができる）になっているか」「局面ごとの各駒（持ち駒を含む）の合法的に
動ける升目の数とその総数」「局面毎の各駒が合法的に利いている（コントロールしている）升目の数とその総数」
「相手玉に、次の手で王手を掛けられる駒の種類と数（持ち駒を含む）およびその王手になる手の数」「彼我の同種
の駒の数を比べて、初期枚数に比べて、どの駒を何枚ゲイン・ロスして、どの駒がイーブンなのか」などの情報を持っ
ていると、将棋の解析が進むと思います。また、いわゆる名局の発掘などにも、たとえば、「互いに詰めろを３回以上
かけた将棋」などの条件で検索をできることになるので、そういう用途にも対応できるのかなと思っています。また、
これらのデータを持っていれば、帰納的に「序盤・中盤・終盤」の定義をすることも可能になるのかなと思っています。
（たとえば、中盤と終盤の境目は双方が、次に王手することが可能な手が○手以上になったら終盤、とか、これは
シンプルすぎてもっと複雑な条件になるでしょうが）。
というわけで、わたしは先日のリアルの場では、なんとなく局面データを持つのは冗長という意見に傾いていました
が、ゆっくり考えると、局面データは持ったほうがいろいろな可能性が広がるのかなと思っています。
Takodori
ginsho
取捨選択は後回しに、指し手情報に含まれているとよいと思われるデータと考えると、形勢データかなと。
先手/後手でポイントを分けあう形式で、AIへの問い合わせによりデータが追記される感じでしょうか。
既存の棋譜形式ではこれが文章化されコメント欄に収められていたわけですが、日本語が読めない
（あるいは将棋独特の言い回しがわからない）プレイヤーにとっては抽出が難しいデータでした。
これをパラメータとして持つことで、重要局面のみの飛ばし見、グラフ利用などの視覚化や、good/badサインの
自動付与などがクライアント側で可能になってくると思います。最終的には各国語コメントの自動生成まで
繋げられたら、棋譜の理想的未来絵図と思います。
それから局面データについてなんですが、すいません、頭が追いつかなくなってきました。。
局面情報が圧縮されている、あるいはハッシュ形式（可逆非可逆問わず）になっている場合、先日の会合で
takodoriさんが要望されていた、局面の部分一致検索は実現できるでしょうか？
（手順の部分一致ではなく、盤面上のキーとなる駒の位置が合致する局面を持つ棋譜の検索です。）
おそらくDBとなる側が非圧縮の局面データを持っていればOKという話なのだと思いますが、DBの実体＝JSON棋譜と
考えると、問い合わせ手続きが面倒になる気がするのですがどうでしょう。
na2hiro
> 局面情報が圧縮されている、あるいはハッシュ形式（可逆非可逆問わず）になっている場合、先日の会合で
> takodoriさんが要望されていた、局面の部分一致検索は実現できるでしょうか？
> （手順の部分一致ではなく、盤面上のキーとなる駒の位置が合致する局面を持つ棋譜の検索です。）
局面に対する一意の文字列を埋め込むのがいいのではないかということなのですが，
局面の部分一致になると話は変わってくると思います．そこから先はデータベース等を用いるべきだと思います．
まず，文字列の一致検索を用いた局面の部分一致検索は現実的に困難です．
たとえば，「11に後手玉がいて22に後手銀がいる」という局面を探すとします．
単純に"11玉"と"22銀"(に相当する局面表記)で検索しても，それらが1つの局面に属しているかどうかがわかりません．
そのファイル内で，20手目で11に玉があり，100手目で22に銀があったけど，同時に存在はしてなかったかもしれないということです．
(以下は非現実的な方法なので軽く読み流してください)
ひとつ思いついた方法は，ある盤面のハッシュを作る時，全ての駒から1個以上選んだ組み合わせを全てに渡っておこない，
それぞれ文字列化する方法です．初期局面で考えます．
1マスについての部分一致を行うために，全ての盤上から1個選び出し，文字列化します．
"11香" "12空白" "13歩" ...
2マスについて (同様に)
"11香12空白" "11香13歩" "11香14空白" ...
とりあえずここまでやれば，2マスまでの部分一致が，文字列の一致検索によってできます．
51に玉がいて61金がいるかどうかは，"51玉61金"という文字列で検索すれば，目的の局面のみひっかかります．
(組み合わせの順序は，数字が小さいほうを先におくなどとして対応します)
というように，文字列の一致検索で局面の部分一致検索をするのは大変です．
では局面をそのまま持っておいて，JSONをパースして，該当マスの一致を調べる方法はどうでしょうか．
これではGoogleなどのWeb検索サービスやOSの検索機能でも部分局面検索をできません．
ローカルファイルでやるとすると，そのための何らかのプログラムを使う訳ですが，そのような専門的な
プログラムなら，データアクセスに特化したデータベースを使うのが自然だし，そうあるべきだと思います．
データベースでは，蓄積されるデータはすぐにアクセスできるような形態にされて保存されます．
例えば，データの先頭に「ここから10バイト目に手数が，20バイト目に盤面がある」などと書いてあって，
そこを見ることで，関係ない所を読まずに目的のデータに対してすばやくアクセスできるものです．
いっぽうJSONなどのテキスト形式は，1バイトずつ読んで行き一旦全てあるいは多くを読み込まないと構造を把握できません．
なので，局面の1マスずつが分かる状態で保っておき，複数の棋譜に渡ってこれを調べるのは，テキスト形式の役割ではないと思います．
そして，データベースの構造についてはそれぞれの開発者がどうするかということだと思います．
(既にJSONをパースしてしまったのなら，検索該当マスの初期マスを持ち，棋譜で移動元座標と移動先座標を初手から見て行って
変化があるかどうか調べる方法もとれそうです．)
> 私は、新しい棋譜形式が将棋というゲームの理解をより深めるというのにより貢献しやすくなるべきだと思っています。
> その立場からすると。
>
> (1)手の情報は多くもてるほうがよい
> (2)局面の情報もあった方がよい。
多くのアイデアが出たのですが，拡張が好きにできるJSONフォーマットの規格としては，
棋譜としての最低限のデータの名前と構造，あるといいデータの名前と構造を決めておき，
それ以外は個別にプログラマが拡張して使うようにするのがいいと思います．
(拡張に際して，なるべくフォーマットの公式サイトや当人のサイトでそれについての説明をするなど，
後発で同じデータを別の名前や構造で保ってしまわないようにするべきですね．)
ちなみに会合で，「自分の読めないデータは捨てるだけ」と言いましたが，正確には読めるけど
意味が分からないというだけで，いじらずにとっておくこともできます．
たんにソフト開発者が必要だと思ったらそこを読めるようにするというだけです．
なんというか，扱う情報が多くなって，ちょっと考えていると大変になってきました．
・なくなると意味がない必要最低限のデータ(座標など)
・ほぼ必ず必要になるデータ(「右」などのpostfix)
・KIFなどで慣例的に保存される情報
・同一局面検索のための盤面データ
これらをひとまず詰めたいです．
今までの話を元にしたサンプルのフォーマットを作ってみようと思います．
ginsho
詳しい説明をありがとうございました。
部分一致局面の検索キーは指し手でなく局面情報（ハッシュ化が検討されている、SFENに類するデータ）の一部、
検索対象もまた同様の局面情報記述を持つファイル群、という前提での質問でしたがわかりづらかったですね。。
ごめんなさい、NHK杯の棋譜を例に書き直します。
NHK杯の棋譜は全局面情報が非圧縮の文字列で記述されています。
（参考：ず さんのサイトのから直接棋譜を閲覧できます）
http://shogi.zukeran.org/tools/nhk2ki2.html
9月18日のNHK杯、郷田九段対金井五段の対局の最終局面109手目の場合、局面情報の記述は以下のようになっています。
ひとつの駒が英数字二文字＆空きマス圧縮なしで表現されているのでむちゃくちゃ長いのですが。。
※正確には、さらにその手の移動駒の記述が末尾に入ります。
p=1b000000000004001b0000001600000000001d00191d001d10001d000000171d001d00000e1d0000000800000005000e00000e0e000000000a0e0e0200000e000008000000000e000c000007001500000071;
JSON棋譜が上記のような非圧縮のストレートな局面情報を持っている場合、1三の後手歩と3三の後手桂だけを選び、
複数の棋譜ファイルを対象に部分一致局面を探す場合は、
/.{18}.{18}1d..19.{12}.{18}.{18}.{18}.{18}.{18}.{18}/
みたいな正規表現で該当ファイルをピックアップできると思います。
しかし非可逆のハッシュ、あるいはSFENのような圧縮記述ですと上記のようにシンプルな検索が
出来なくなるのでは？と思い、先の質問となった次第です。実際、研究用途の検索を考えると完全一致局面より
は部分一致検索の方が重宝しする場面が多そうな気もしまして。
わかりにくくてスミマセン！
しかしna2hiroさんの仰るとおり、専用ソフトに頼るべき機能の線引きも必要と思います。
なので、もしも盤面のデータだけで1駒1文字（NHK式はさすがに長過ぎ）、計81文字（駒台上の駒はさらに別）という内容で
使ってしまって大丈夫そうな状況であれば、局面記述方の候補として検討をお願いいたしたい所存です。
先手後手の駒を成り駒を含めてすべて異なる文字で記述する場合、大文字小文字の区別が不可だとアルファベットだけでは
無理なので、なにか工夫をしないといけないですが。。
＞ なんというか，扱う情報が多くなって，ちょっと考えていると大変になってきました．
＞ ・ほぼ必ず必要になるデータ(「右」などのpostfix)
＞ ・KIFなどで慣例的に保存される情報
＞ ・同一局面検索のための盤面データ
＞ これらをひとまず詰めたいです．
＞ 今までの話を元にしたサンプルのフォーマットを作ってみようと思います．
よろしくお願いします！
拙作KZ制作時に、KIF、CSA、PSNの記述方法を比較するために作ったExcelの資料がありますので、dropboxに上げておきます。
PSNの箇所など不正確＆わかりにくい記述が多々あるかと思うんですが、なにかしらお役に立てましたら幸いナリです。
http://dl.dropbox.com/u/2385159/kifu_format.zip
na2hiro
> 検索対象もまた同様の局面情報記述を持つファイル群、という前提での質問でしたがわかりづらかったですね。。
いえ，棋譜ではなく1局面ごとに，11に玉がいる局面には"11玉"という文字列が含まれているような表現を考えていました．
とくに読み違いはないような気がします．
> p=1b000000000004001b0000001600000000001d00191d001d10001d000000171d001d00000e1d0000000800000005000e00000e0e000000000a0e0e0200000e000008000000000e000c000007001500000071;
>
> JSON棋譜が上記のような非圧縮のストレートな局面情報を持っている場合、1三の後手歩と3三の後手桂だけを選び、
> 複数の棋譜ファイルを対象に部分一致局面を探す場合は、
>
> /.{18}.{18}1d..19.{12}.{18}.{18}.{18}.{18}.{18}.{18}/
>
> みたいな正規表現で該当ファイルをピックアップできると思います。
> しかし非可逆のハッシュ、あるいはSFENのような圧縮記述ですと上記のようにシンプルな検索が
> 出来なくなるのでは？と思い、先の質問となった次第です。実際、研究用途の検索を考えると完全一致局面より
> は部分一致検索の方が重宝しする場面が多そうな気もしまして。
たしかに固定長で盤面符号を持てば正規表現で検索できます．
しかしJSONテキストのままの検索を常用するのが得策とは思えないのですが…
簡易的なものとしてあったほうがいいというならいいと思います．
他の方の意見も伺いたいです．
これを採用するなら，Web検索の局面一致のために大文字小文字を同一視すると，
だいたい0-9a-zの36通りを1バイトで表せます．マスの状態は 空白1+先後2*種類14=29なので
ちょうど1マス1バイトで表せますね．81マスで81バイト．
あとは手番と持ち駒ですが，単純にやると手番1バイト駒7種類1バイトずつ(36枚以下なので)で8バイト．
縮めるなら，手番1ビット，歩5ビット(0~18枚<=2^5)，桂香銀金3ビット(0~4枚<=2^3)*4種，
飛角2ビット(0~2枚<=2^2)*2種
で22ビット，1バイトで5ビット表せるので5バイト分ですね．
1局面を86~89バイトで表すことになりそうです．
> わかりました。とりあえず現状のJSON棋譜についてはshogitterからダウンロードして予習しておきます。
将棋ったーのJSONはここで話しているのとは違って独特な部分があるので
あまり参考にならないかもしれません．
余談ですが，この新形式ができたら，将棋ったーもそれに沿うように変更できればと思っています．
新形式の拡張として，棋譜で，移動元，移動先，駒種の他に，他のマスの差分情報を持つものです．
将棋ったーの棋譜は移動元という区別はあまりしておらず，全てマスの差分なので
扱いづらい部分があったので，移動元移動先と差分を組み合わせると良いと思います．
(正確には，差分の1番目が移動先の座標，2番目が移動元になっています)
例えばキルケ(取られた駒が初期位置に戻る)で，24歩と角を取ってその角が22に戻る場合，
{
from: [2,5],
to: [2,4],
species: "歩",
diff: [
{
type: "持ち駒",
player: "先手",
species: "角",
num: -1
},
{
type: "盤面",
place: [2,2],
species: "角",
player: "後手"
}
]
}
ふつうに24歩と取った後，diffに従って先手の角を1枚減らして22に置く感じです．
diffがなければふつうの将棋と同じです．
> 拙作KZ制作時に、KIF、CSA、PSNの記述方法を比較するために作ったExcelの資料がありますので、dropboxに上げておきます。
> PSNの箇所など不正確＆わかりにくい記述が多々あるかと思うんですが、なにかしらお役に立てましたら幸いナリです。
>
> http://dl.dropbox.com/u/2385159/kifu_format.zip
ありがとうございます．参考にしたいと思います．
--
na2hiro (http://81.la, http://shogitter.com)
twitter: @na2hiro
na2hiro
https://docs.google.com/spreadsheet/ccc?key=0AmOwH-45c-29dHVSdmcxeHRsOHBaYXNVaU5pRWxNemc&hl=ja
終局サインなどはCSAが十分に対応しているので，これをそのまま使うようにしてもいいかもしれませんね．
とりあえず棋譜フォーマット
http://code.google.com/p/shogi-format/wiki/Format_Candidate
とルールフォーマット
http://code.google.com/p/shogi-format/wiki/Rule_Format
を書いてみたので，突っ込みお願いします．
棋譜のところは省略が多いのでなんとも言えないと思いますが，後々書きます．もしくはどなたかお願いします．
tarumi
お世話になっています AND/OR はじめまして皆様。
ご挨拶が遅くなり申し訳ありません。
日常業務に追われていてなかなかメールの細かいところまでフォローできていませんがよろしくお願いします。
ところで gmail のアドレスで登録しまったのですが、発信しづらいので大学のアドレスに修正をしたいのです。
北尾さんにお願いすればよいのでしょうか？ (tar...@eng.kagawa-u.ac.jp)
さて、このトピックスで局面ハッシュの話が出ていました。
我々のところでは局面検索用にハッシュを考えていたのですが先日やめました。
局面はそのままでも530ビット程度で表現できるためです。（独自形式ですが 534bitで表現しています）
そうするとハッシュの衝突も考慮しなくてよくなるので。
ただし、部分一致局面の検索等については考慮していませんのでここで議論されているニーズには合っていないのかもしれません。
fan takeshi
棋譜フォーマットの草案を拝見しました。
ハッシュ値を含む際に、1マス毎の表記を候補に入れているのは、
ginshoさんのSFENでは正規表現による部分局面検索がスマートに出来ないのでは？
という発言を受けてのことだと思いますが、SFENでも出来ると思います。
例えば、先手振り飛車穴熊 対 後手居飛車穴熊の例を考えてみます。
玉周辺部分だけを考えたものをSFENで表すと次のようになります。
6gnk/6gsl/6ppp/9/9/9/6PPP/6GSL/6GNK
これを局面図画像に直すと次のリンクになります。
http://sfenreader.appspot.com/sfen?sfen=6gnk%2F6gsl%2F6ppp%2F9%2F9%2F9%2F6PPP%2F6GSL%2F6GNK%0D%0A
そしてこれを含む局面図を検索したいと思ったら次のような正規表現になると思います。
.*gnk\/.*gsl\/.*ppp\/.*\/.*\/.*\/.*PPP\/.*GSL\/.*GNK
＃間違い、反例があったらご指摘お願いします。
.*の部分はなんでもOKの意味で、/は正規表現では特別な文字なのでバックスラッシュでエスケープしてます。
banhashは同一局面図検索を高速に行うなどの目的で必要だと思いますが、
それとは別にsfenというフィールドを用意して、局面のsfen文字列をそのまま入れることは出来ないでしょうか。
ただ、膨大なsfen文字列を正規表現で検索して
高速に処理が出来るかどうかは一考の余地ありだとは思います。
＞ginshoさん
以前出たsfenの拡張は最終着手の色分けだったと思いますが、
今回は棋譜データそのものの策定なので、
個人的にはsfenそのものの拡張には意味を見出していないのですがどうでしょうか
--
fantakeshi <fanta...@gmail.com>
na2hiro
> 北尾さんにお願いすればよいのでしょうか？ (tar...@eng.kagawa-u.ac.jp)
はじめまして．よろしくお願いします．
脱退は参加者自らおこなえるようです．
http://groups.google.com/support/bin/answer.py?hl=jp&answer=46608
> さて、このトピックスで局面ハッシュの話が出ていました。
> 我々のところでは局面検索用にハッシュを考えていたのですが先日やめました。
> 局面はそのままでも530ビット程度で表現できるためです。（独自形式ですが 534bitで表現しています）
> そうするとハッシュの衝突も考慮しなくてよくなるので。
確かに単方向だと衝突する可能性はありますね．
ただハッシュ長を長くすれば十分対応できるのではないかと思います．
Zobrist Hashingは，XORをとるだけなので，今まで64bitだったのをあとから128bitに拡張すると
いうことになっても，頭の64bitはそのまま残して末尾64bitを足すだけで良いので，
最悪あとで衝突が見つかって伸ばしたくなったとしても，混乱は避けられると思います．
128bitになったあとでも，先頭の64bitだけ切り取って検索すれば，古い64bitのハッシュを使った
棋譜を検索できますので．
> 玉周辺部分だけを考えたものをSFENで表すと次のようになります。
> 6gnk/6gsl/6ppp/9/9/9/6PPP/6GSL/6GNK
>
> これを局面図画像に直すと次のリンクになります。
> http://sfenreader.appspot.com/sfen?sfen=6gnk%2F6gsl%2F6ppp%2F9%2F9%2F9%2F6PPP%2F6GSL%2F6GNK%0D%0A
>
> そしてこれを含む局面図を検索したいと思ったら次のような正規表現になると思います。
> .*gnk\/.*gsl\/.*ppp\/.*\/.*\/.*\/.*PPP\/.*GSL\/.*GNK
> ＃間違い、反例があったらご指摘お願いします。
それは探したいマスが両端にあるからできるのであって，例えばある段の5筋に歩があるのを検索する時，
/1P7/ と /4P4/ の区別を正規表現で行うのはかなり面倒くさい気がします．
> banhashは同一局面図検索を高速に行うなどの目的で必要だと思いますが、
> それとは別にsfenというフィールドを用意して、局面のsfen文字列をそのまま入れることは出来ないでしょうか。
うーん，やはり1手ずつ局面図自体を持つありがたみは，Web検索エンジン等の局面検索対応以外には
ないと思うので，仕様に含める必要があるとは思えないのですが・・・．
JSONとして読み込めば，初手から並べて行って局面を作れますので．何に使うのかがいまいちピンと来ていません．
fan takeshi
>> 6gnk/6gsl/6ppp/9/9/9/6PPP/6GSL/6GNK
>>
>> これを局面図画像に直すと次のリンクになります。
>> http://sfenreader.appspot.com/sfen?sfen=6gnk%2F6gsl%2F6ppp%2F9%2F9%2F9%2F6PPP%2F6GSL%2F6GNK%0D%0A
>>
>> そしてこれを含む局面図を検索したいと思ったら次のような正規表現になると思います。
>> .*gnk\/.*gsl\/.*ppp\/.*\/.*\/.*\/.*PPP\/.*GSL\/.*GNK
>> ＃間違い、反例があったらご指摘お願いします。
>
> それは探したいマスが両端にあるからできるのであって，例えばある段の5筋に歩があるのを検索する時，
> /1P7/ と /4P4/ の区別を正規表現で行うのはかなり面倒くさい気がします．
すみません、書いてから自分でも布団の中で反例に気が付きました。
SFEN文字列で正規表現だけで部分一致検索を実現するのは、例示されたものだけでも不可能だと思います。。。
> うーん，やはり1手ずつ局面図自体を持つありがたみは，Web検索エンジン等の局面検索対応以外には
> ないと思うので，仕様に含める必要があるとは思えないのですが・・・．
> JSONとして読み込めば，初手から並べて行って局面を作れますので．何に使うのかがいまいちピンと来ていません．
JSONは冗長な情報を持てるので、無いよりあった方がいいのでは、くらいの気持ちで書きました。
しかし、局面の情報について直接JSONのテキスト検索をしないという方針に立てば、
確かに有効な場面が思いつきませんでした。
一晩立ってよくよくスレッドを見返してみたら一周遅れの議論だったかもしれません。
すみませんでした。
＃スレッドの特定の発言に対してURLとか割り振られないんでしょうかね？
--
fantakeshi <fanta...@gmail.com>
na2hiro
> すみませんでした。
いえいえ．
どういう話なのかが他の方にも分かりやすくなって良かったと思います．
> ＃スレッドの特定の発言に対してURLとか割り振られないんでしょうかね？
それぞれの発言の右上にある「詳細オプション」の「個々のメッセージ」にありました．
http://groups.google.com/group/shogi-developers/msg/26933d249896570c
ginsho
どうぞよろしくお願いします。
先日の会合ではうまくskype陣のお話を伺うことができずすみませんでした。
学生さんたちが取り組んでおられる感想戦の手順記録システム（？）
チャンスがあればぜひ拝見させていただきたいと思ってます。
＞fan takeshiさん
こちらでもよろしくお願いします。
>以前出たsfenの拡張は最終着手の色分けだったと思いますが、
>今回は棋譜データそのものの策定なので、
>個人的にはsfenそのものの拡張には意味を見出していないのですがどうでしょうか
SFENに直前に動いた駒の情報を付加する記述（ハイライト表示用途）、また駒名称に
用いる文字などは棋譜が持つ局面情報と書式が揃っていた方が、変換の処理もなく楽ちんです。
ですので現状のSFENの他に、JSON棋譜で使用される記述に足並みをそろえた
代替記述方があるといいかなと思いました。
（先に出た案に従えば、駒を0-9a-zで表す記述方など）
が、棋譜自体が局面情報を持たないのであれば、ビューア等表示側プログラムが変換機能を
提供することになると思うので、現状特に気にすることはなさそうではありますね。
＞na2hiroさん
例えば電子書籍へのエンベッド用途に軽量の動く局面図ビューアなどを作る場合、駒の移動を
トレース不要な棋譜を利用できれば制作の敷き居はすこぶる低く、ありがたい話です。
また、デスクトップ、あるいはEvernote、Dropbox等クラウド上にぞんざいに放り込まれた
棋譜ファイル群から局面部分一致検索で棋譜を釣り上げられるとしたらこれもまた魅力ある話で
有用な利用方法はむしろユーザ側が見つけていくでしょう。
（そしてまた、専用ソフトを使えば出来るよ、的な話はそれらの利用が難しい海外の将棋ファンには
なるべくしたくないのです）
ですがJSON棋譜に馴染まない、荷が重いということであれば不採用いたしかたなしと思います。
ただ、議論の中で出てきた局面記述の方法等はこのまま捨て置くのは非情に勿体ない気がしますので、
局面情報ベースの棋譜フォーマットというのを、ひとつ別に考えてみたいと思います。
方向性の異なる棋譜形式を比較しつつ両者が仕様決めをしていけたら、けっこう理想的かなと。
とりあえず近々別トピにてアジェンダっぽいものをまとめてみようと思います。
na2hiro
> トレース不要な棋譜を利用できれば制作の敷き居はすこぶる低く、ありがたい話です。
ただそういう場合でも，JSONを既に読み込んでいるという前提があるので，
文字列から盤面をおこすより移動の1手を見たほうが簡単だし盤面全体を
描画し直す必要がなくて軽いと思います．つまり，初期局面で1手目が
{from:[7,7], to: [7,6], 種類(仮):歩(仮)} (初手76歩の棋譜)
ならば，77の地点を空白で描画し，76の地点を歩で描画すれば，それで1手再生になります．
> また、デスクトップ、あるいはEvernote、Dropbox等クラウド上にぞんざいに放り込まれた
> 棋譜ファイル群から局面部分一致検索で棋譜を釣り上げられるとしたらこれもまた魅力ある話で
> 有用な利用方法はむしろユーザ側が見つけていくでしょう。
> （そしてまた、専用ソフトを使えば出来るよ、的な話はそれらの利用が難しい海外の将棋ファンには
> なるべくしたくないのです）
それなら可逆でもいいと思います．
http://code.google.com/p/shogi-format/wiki/Format_Candidate
ここの1マス1バイト方式という感じでいいでしょうかね．
> ただ、議論の中で出てきた局面記述の方法等はこのまま捨て置くのは非情に勿体ない気がしますので、
> 局面情報ベースの棋譜フォーマットというのを、ひとつ別に考えてみたいと思います。
> 方向性の異なる棋譜形式を比較しつつ両者が仕様決めをしていけたら、けっこう理想的かなと。
> とりあえず近々別トピにてアジェンダっぽいものをまとめてみようと思います。
na2hiro
プレゼン発表させていただきました．
当日の資料はこちらです．
http://bit.ly/jsonshogi
また，プレゼンでちょっと中途半端だったサンプルを補充したものをアップロードしました．
http://81.la/jsonshogi
柿木さんにも，概ねJSON棋譜の趣旨に理解を示していただきましたが，数年前からXML棋譜の構想を
持っていながらなかなか表に出そうということにならないことから，やはり既存のKIFが巨大になっていて
取って代わるのは相当の努力が必要という考えをお持ちであると感じられました．
局面ハッシュの埋め込みなど，JSONそのものに利用者にとっての直接のメリットをもたらす機能などに
これから議題をシフトしていく必要がありそうです．