 |
(GPS将棋開発参加記録)
|
|
|
(GPS将棋開発参加記録)
|
floodgateのレーティングから将棋クラブ24のレーティングを予想する方法を少し変えています。当初は+450点で始めましたが、YSSのレーティングがそれなりに変動するので、YSSが常に2300になるように移動幅を調整することにしました。その結果、参加者の変動に対して以前より安定した値になっていると思います。(一方、YSSの改善があってもレーティングが変わらないので、山下さんはつまらないかもしれません。すみません。) 将来的には複数のプログラムの対応関係を使って補正できればと思います。
それに伴い、レーティンググラフにも両方の値を併記してみました。この日記に載せているグラフもそうですが、赤がfloodgateのレーティングで、緑が24のレーティング予想です。赤い線は最近下降気味ですが、緑を見るとgpsが弱くなったというわけではないようです(強くなってもいませんが…)。グラフの張りかたなどはこちらを御覧ください。全てのプログラムの画像が、毎日自動で更新されています。
レーティングではプレイヤの強さのようなものをモデル化していて、プレイヤが対局する場合に二人のレーティングの値の差から勝率が計算できます。(floodgateで利用しているレーティングの計算モデルはこちらです。) そこで、レーティングから計算した勝率と、実際の対局での勝率を比較してみました。前者より後者が高ければ相性が良い、逆ならば悪い、と言えるかもしれません。
結果を表にまとめます。順に、「相性」が良い側のプレイヤ、反対のプレイヤ、実際の勝率、レーティングから予想される勝率、有意水準(+で10%, ++で5%)です。
| player1 | player2 | win% (real) | expected | significance level |
|---|---|---|---|---|
| gps_normal | MyMove900 | 0.992 | 0.968 | ++ |
| Kakinoki_Test | gps_normal | 0.507 | 0.419 | + |
| spear900_note | KShogi | 0.600 | 0.194 | + |
| MyMove900 | gps500 | 0.748 | 0.678 | + |
| misaki900 | coredump | 0.571 | 0.270 | + |
| misaki900 | cat18_on_note | 0.742 | 0.615 | + |
| gps500 | spear900_note | 0.333 | 0.091 | ++ |
| gps500 | misaki900 | 0.508 | 0.361 | ++ |
結論としては、有意に差がある組合せは全体のごく一部で、概ね現実に即したレーティングがついているようです。
spear900_noteのKShogiに対する勝率がずいぶん良いですが、対局数がまだ少なく今後に注目です。(そのため有意水準が低くなっています)
gps500が3回登場しますが、通常探索に比べて詰将棋が得意であるとか、自然な弱さになっていないなどの原因が想像されます。最近は、組合せ奇数の時にしか登場しないので、全体への影響は少なくなっていくと期待します。他に、gps_normalはMyMove900が得意のようですが、これはなぜでしょうね。
この統計で有意な組合せ(が現れた場合)は、プレイヤごとのページ(show-player.cgi)に自動で印を付けるようにしています。ご利用ください。
0秒で指すとサーバが指手を受け取らないのではないかという連絡をいただいています。こちらではまだ再現できていませんが、引き続き怪しそうな点を調査してみます。(3/11追記)報告いただいた件と関係があるか不明ですが、クライアントが二手指しをするとサーバが指手を捨ててしまうことは分かりました。ひとまず二手指しを反則負けとして扱う予定です(csaプロトコルの規定が見付からないですが、問題ないですよね)。引き続き他の条件を探しています。
また、千日手で終わった場合に、引き金となった指手が送信されないとの連絡もいただいております。こちらでは再現できていないため、類似の例に遭遇されましたらぜひ時刻と棋譜をお知らせください。よろしくお願いします。
サーバが指し手を受け取らないらしい現象がその後も時々、起きているので、パケットモニタでパケットの送受信を調べました。<br>この現象が起きる直前に、サーバが指し手を送信し、こちらからACKパケットを送る動作を何度も繰り返していました。<br>この辺は詳しくないのですが、この問題は、アプリケーションのレベルではなく、ネットワークの回線や物理的な問題ではないかと思っています。<br>開始時のデータを受け取る際も何度も再送信している場合もありました。
追加の情報ありがとうございます。上位層に潜在的なバグがあり、回線が不安定な時にのみ顕在化するということも考えられますので、こちらでももう少し追求したいと思います。<br>再送信を繰り返すうちに、サーバが送信中、クライアントが送信済みの状態になってしまうとまずいのですが、そうなるケースは今のところ思いあたりません。
自分で書いたプロトコル文書を再読してみると、確かに「2つのクライアントが交互に指す」等の規定を明確に書いてないですね。「クライアントは将棋のルールに則って指し手を送信する」とでも書いておけば、それが間接的にでも交互に指すことを要件に含めたことになりそうですが、それも明記してない(汗)。<br>ちなみにCSAのサーバは、2手指しがあった場合、黙って#ILLEGAL_MOVEを送って対局終了にしています。はっきり書いてないとはいえ2手指しは一応プロトコル違反なのですが、プロトコル文書たるもの、プロトコル違反があった場合の挙動も広範に記述するものなのでしょうか？
もはや世界最大のコンピュータ将棋対局データベースとなったwdoorですが、先手勝率や千日手率はわかりますでしょうか？ 加えてレーティング差と先手勝率の相関がわかれば完璧ですね。<br>多分コンピュータ将棋は先後がほとんど互角だろうと予想していますが、意外と有利・不利があったら選手権のルールも考え直す必要があるかもしれません。
http://wdoor.c.u-tokyo.ac.jp/shogi/tools/view/index.cgi?go_last=on&csa=http%3A%2F%2Fwdoor.c.u-tokyo.ac.jp%2Fshogi%2Flogs%2FLATEST%2Fwdoor%2Bfloodgate-900-0%2Busapyon-on-note%2Bmisaki900%2B20080313103003.csa<br><br>において、34手目△84飛を受け取った後、うさぴょんから▲65角を送っているのですが、これに対して、その手に何秒かかったという返信が来ないまま、usapyon-on-noteが受信待ちでtime_upになったようです。<br><br>もしかすると、ほとんど同じタイミングで、KEEP_ALIVEを送っているかも知れません。<br><br>何かの参考になればー。<br><br>単に通信エラーかも知れませんが(--;
山田さん<br>コメントありがとうございます。無視するのとどちらが良いかと迷いましたが、CSAのサーバに合わせて反則扱いにしたいと思います。<br>プロトコルですが、連続して自動対局を続けるという観点では、クライアントからサーバに送られるメッセージは全て定義されている必要があります。 (避けたい例を極端に作ると、「#NITEZASHI!! と結果を伝えたら、勝った側のクライアントが(も)落ちてしまって、次の対局に移れないという不利益が出る」というような状況です。) #ILLEGAL_MOVEの準用は人間には類推可能な範囲ですが、タイミングやその直前に送られる指手の手番など細かい違いがあるため、プロトコルに記載されている方が安定した運用ができると思います。別の案としては、反則した側が投了したかのように相手に伝える(サーバが演技する)ことも可能です。shogi- serverでは回線切断があった場合にそのように処理しています。こちらの方がクライアントを作る手間は少ないかもしれません。<br>しかし、csa選手権においては当面問題がなさそうなので、長期的な課題になるでしょうか。
うさぴょんの育ての親さん<br>事例の報告ありがとうございます。タイミングエラーと並行して、個々の局面に起因する原因がないかも探していたところだったので助かります。