geek な日々

級位者の愉快な対局 次の一手 △横歩取り3三歩戦法

もう級位者でもなくなったのだが、当時のテイスト溢れる対局を経験したので報告する。
横歩取りで▲3四飛とした後、後手も△7六飛としてしまうと、▲2二角成の強襲があって、△同銀でも△同金でも金銀の連結が外れ、飛車が成りこんでゲームセット、という「だから後手も先手の真似して横歩を取ってはいけませんよ!」的な進行がよく紹介されているが、このときの飛車の成りこみを防ぐ驚愕の面白戦法が以下の△3三歩。

正直、指されて驚いた(笑)。
さて、どう対応したらいいだろう?


次の一手的には▲3二馬が正解だが、▲3一馬や▲8四飛車、▲2一馬なども先手勝勢~優勢(elmo 2017 調べ)。
▲3二馬△3四歩と飛車を取れば、▲3一馬で先手金銀得。▲5三馬の狙いも残っている。
▲3二馬△同銀と馬を取れば、▲2四飛△2三歩打。▲2八飛とひいても金得の上に▲2二歩打の狙いが残る。
やはり、「横歩を取るのは先手の権利」なんだろうが、相手が高段者の場合、ここからでも勝ち切るのは大変なんだろうなあとは思う。

将棋実況系 YouTuber 神動画 その2

前回の続き

★アゲアゲさん

雁木VS左美濃急戦‥終盤の寄せが圧巻。実況のハイテンションともマッチしてます。




ボヤ騒ぎと著作権

さきほどの週末、twitter とブログが連動して炎上騒ぎがった。ネットは長いことやっているが、この「炎上」というものに立ち会ったことは一度もないので、若干の興味をもってことのなりゆきをチラチラ眺めていた。顛末を大雑把に言えば、『将棋研究系ブロガーの S氏が、twitter で活躍中の将棋研究家 Y氏が twitter 上で公開している資料を素に Y氏に無断で記事にして公開。S氏や周囲の人から批難された』というもの。
ちなみに、

・無断引用したとされる S氏のブログ記事
http://archive.is/qMHpw

・無断引用されたと主張する Y氏の twitter モーメント
http://archive.is/kpxPH

です。
この件に関しては、直接の何のかかわりもないし、論争となっている素材の質からして特に何も言うことはないのだが、これに関連して言いたいことはそれこそ山のようにあって、それはなにかというとネット上で使える資料に対する日本人の著作権・ライセンスに対する認識みたいなものだ。

以前にも書いたのだが、多くの日本人が
・著作権と特許権(のうち特に排他的独占権に該当する部分)を混同
・著作権の保護対象を勝手に拡大解釈
しているように思えるからだ。「多くの日本人が」と書いたが、ここら辺しっかり認識できている人もいて、それは実は開発系のエンジニアだったりバリ理系の研究者だったりする。まー、仕事のアウトプットが著作物だったり特許だったりするので、当然といえば当然か。

ここらへんわきまえた人たちは「公開していたモノをパクられたとかいうのはナンセンス」ということがわかっているので、おそらくこういったボヤ騒ぎになること自体がない。しかも、表現形式がメモ書き程度のもので、排他的独占権を主張するのはそっちの方が恥ずかしい、ということを経験的に学んでいるので、仮に「パクられた」としても「まあしょうがないか」と思う程度だろう。

もちろん、逆の立場になることもある。公開されているモノでも「素材は良いのに、その良さが活かしきれていない」と感じることはたびたびあり、その場合、その素材を元に適宜改変を加えて活用を図っていく。が、素材そのままを使用するというのは、動機からみてありえない。
ちょっと具体的な話をする。
将棋関連に絡めて言えば、私は、今、JavaScript で動く棋譜再生ビューアーをつくっているが、この元ネタは NHK のサイトにあった JavaScript である。
まず、これをそっくりそのまま使用するのは明らかに著作権に抵触するので、表面的には将棋盤まわりのデザインを変えた。
次に、(これが元ネタを改変しようと思った主な理由なのだが)コメント出力できるように内部ロジックの拡張を図った。元ネタのソースを読むとコメントも定義されているのだが、残念ながらこれを活用するような実装はまったくなされていなかったのだ。
さらに、「NHK が定義するデータ形式(私はこれを nkif と呼んでいる)だけでは実用上役に立たない」と考え、kif 形式をサポートすることにした。
ここまできてようやく「これなら著作権云々に抵触することはないだろう」と改変した JavaScript を使って記事を作成、ブログ上にて公開した。
一応、元ネタもわかるように記載しているが、正直なところ、これも不要だろう。機能拡張まで図ってしまえば、それはもう別のプログラムとみなしてもかまわないだろうから。
実際の開発などというのは、こういった具合に進んでいく訳で、上記のボヤ騒ぎにあったような単純すぎる図式におちこむというのは、諸々の制約を適当にさばいていくとあまりおこらないことは容易に想像がつく。
そして、(こっちの方が重要なことかもしれないので)付け加えておくと、私の JavaScript を誰かが無断で使用したとしてもおそらく私は、何のクレームもつけないだろう。それは、プログラムには著作権があるし、私は著作権を放棄したわけではないが、誰が書いても似たような表現になるプログラムが保護の対象になることはなく、なったとしても相当弱いということを私が知っているからだ。
そもそも、クライアントサイドで動く JavaScript 自体がコピーし放題、ソースも見放題な訳で、その言語を選んで公開した時点で、そうなることもある程度は織り込んでいる。

(地味に続く予定)

nkif ファイルと DB と局面検索

今日は、JSKifuForWP のコードをいじる。
コメント出力も可能になった。
JSKifuForWP は読み込むことのできるデータ形式は、nkif 形式のみである。nkif というのは、私が勝手に名付けた名称で、その出自が某放送局のためこの名前となっている (笑)。
今日の作業でそのデータ構造はほぼ理解した。

nkif は一局面を例えば

p=1b191716101617191b0014000000000012001d1d1d1d1d1d1d1d1d000000000000000000000000000000000000000e000000000000000e000e0e0e0e0e0e0e0003000000000005000c0a08070207080a0c26;
h1=;
h2=;

という形で表す。p は盤面の駒配置、h1 は先手の持ち駒、h2 は後手の持ち駒、である。
p はここでも調べていた。1一が 1b で香、2一が 19 で桂、‥‥というのはわかっていたのだが、これだと 81 * 2 = 162 文字で盤面の駒配置はすべて決定されるはずだが、実際には、164 文字ある。最後の 26 が余計だ。
今までこれがわからなかったのだが、わかってみればなんことはない、これは着手位置を表すマーカー画像の位置そのものだった。初手▲2六歩と飛車先を突いたので、こうなっている次第。余計な情報なので落としてもいいのかもしれない。

そこまでわかったので、テスト的にデータベースも作ってみた。とりあえず三局ほどデータを挿入。

この状態で

SELECT * FROM tbl_kifu where kifu like '%p=1b19171610161719‥(略)‥0a0c26;%'

を実行(SQL文はいつまでたっても慣れないっす)。
結果は、

と同一局面(初手▲2六歩)を正しく2件ひろってくる。
問題の処理時間は、

と約 30 ms 。
これだと100局程度でも、同一局面をひろってくるのに数秒かかりそう。
んー、ちょっと遅いかな。

感想としては

・それっぽいシステムは組めそう
・が、「こなれた」システムをつくるのはそれなりのノウハウが必要

と思った。

むー、私、データベースとか検索とか経験値少ないんだよねー。

大人のための将棋再入門 4 脳内評価関数更新用早石田くん対策

ウォーズ低級位時は、相手が棒銀・中飛車・早石田を指してくる場合が本当に多い。
対策立ててないと
の局面で恐怖を覚えます。「飛車が危ない」と。
要するに、この後、どこかで▲7四歩△同歩▲2二角成△同銀と進んだ場合の▲5五角の飛車取りを予想して身構えるわけですね。
この手には、△3三角打と自陣角を打つのが好手です(おそらく定跡にもなっていると思う)。
つまり、飛車を取らせるわけです。
落ち着いて考えると▲8二角成△同銀としたところで単なる飛車角交換ですし、この後、後手陣に飛車を打ち込む隙はありません。むしろ△9九角成を防ぐために後手に回ることになります。
この進行を早石田対策としてとりあえず覚えておいてもいいですし、

 どんなときでも 飛車>角 → 序盤は飛車より角

というふうに(おそらく)誤った脳内評価関数を更新しておきましょう。

この後の進行はこれなんか参考にしてください。

大人のための将棋再入門 3 シケプリ風まとめと若干の考察


起源:古代インドのチャトランガがその起源といわれている。チャトランガが西洋に渡りチェスとなり、日本に渡って将棋となった。両者は、独自の発展を遂げていたが、ボードゲーム系の AI というくくりでみると、例えば著名なコンピュータ将棋プログラム YaneuraOu が コンピュータチェスプログラム StockFish のコードから多大な影響を受けているなどの例があり、両者の関連性は無視できない。

ゲーム理論上の分類二人零和有限確定完全情報ゲームに分類される。

理論的性質からのアプローチ:二人零和有限確定完全情報ゲームは、「理論上は完全な先読みが可能であり、双方のプレーヤーが最善手を打てば、必ず先手必勝か後手必勝か引き分けかが決まる」が、将棋の場合、その完全な先読み(完全解析)はいまだなされておらず、仮になされたとしても(特にプレイヤーが人間の場合には)その結果に基づいて指し手を決定する具体的な手段を用意するのは現実的ではない。現実的には、コンピュータ将棋においては、ミニマックス法などの定式化されたアルゴリズムを利用して指し手を決定している。

ミニマックス法などに関しては、こちらに実例を挙げて軽く触れておきました。そこでも触れましたが、実際の差し手決定には、「探索」に負けず劣らず「局面評価」が重要であることを強調しておきました。


人間の対局を振り返ってみると、定跡から外れた局面などは、人間もミニマックスに近い思考方法を取っていることがわかります。つまり、何手か先を読んで、そのときの局面を「駒得しているから良い」とか「駒損はしているが先手を取っているので指せる」などと評価して現実的な指し手を決定しているわけですね。
で、困るのは、人間は、なかなか質の良い評価関数を獲得するのが難しいってことです。

 ヘボ将棋 王より飛車を かわいがり

なんて川柳はあまりに有名ですね。

特に、大人になると意識的にやらないとなかなか脳内評価関数(?)は更新されないので、ソフトを使った検討などでは、このことを意識しながらおこなうと良いでしょう。
まず、上の格言的川柳が批判するような局面が頻発する早石田の対策から考えましょう。
なお、評価関数の評価に関してはこんなことがいえると思います。

評価関数の評価:完全解析がなされていない以上、これとの比較において各種ソフトの評価関数の優劣を決めることはできない。現実的には、異なる評価関数を持つソフト同士の対戦結果から「レーティング」を求め、評価する。


ソフト同士の対局から新しい定跡を抽出しようという動きにはこういった背景があったわけですね。

blogger で JavaScript その2

このブログって JavaScript 使える? ってことで実際にテスト。
現時点では、たいていの端末・ブラウザで表示されているようですが、android スマフォの chrome で表示できていないようです。(下記参照)

****************************************************************






*****************************************************************
(こんな感じ(↓)で設置が進行)

初期処理の描画もできてるし、タッチに反応もしているが(=JavaScript 自体は読み込まれて一部動いている)、再描画されない(=特定の関数が実行されない?)。
なんでだ?

(本番環境wだが、ソースにデバッグ用のアラート関数埋め込む)
関数実行されてる。
んー、クリック位置取得の座標値がおかしい。
原因はどこ?

ここの情報を元にソースコードを修正。PC の chrome では狙い通りの動きをするようになった。

(出先で、android スマフォからこのページを確認 )
げっ、描画もされてない!
canvas 要素のサイズでかすぎたか????

(iPad Pro 9.7 でも確認 ←今ここ)
問題なく表示できてる。

小型機の表示エリアの問題か? android ブラウザの問題か?