ナニゴケのNNを新しくしました。

ナニゴケ – 苔の種類を判別するWEBアプリ
https://www.nanigoke.net/

今回は、判別可能な種に、「アカイチイゴケ」、「コモチフタマタゴケ」、「ジャバウルシゴケ」、「トサカホウオウゴケ」、「ナガサキホウオウゴケ」、「ナメリチョウチンゴケ」が追加されました。また、16400枚だったTrainのデータ数は、19600枚になっています。ネットワークの構造は、微調整程度の変更。TensorFlow.jsのバージョンは、最新の2系にしました(どう変わったのかはぜんぜん知らん(笑))。それから、学習データの水増しにおいての左右フリップを、20%だけ行うようにしました。これ、今まで私は絶対絶対絶対絶対やりたくなかったのですが、あまり自己満足だけを追い求めるのは、使ってくださる方たちに悪い気がして、今回少し妥協しました。でも、今後は少しずつ割合を減らしていって、いつかはまた0%に戻したいと思います(「じゃないとダメ」って苔が言ってるような気がする…)。ちなみに、詳しく調べたわけではありませんが、今回ロスがぐっと減ってて少しムカついています(笑)。

その他、今回はさまざまな細かい修正をいれているのですが、主なものだけ列挙しておくと、まず、iOSからファイルを読み込んだ時に画像が回転することがもともとあって、これは一応すでに対応済みだったのですが、最新のiOS(バージョン13.4から?)ではなにか変わったのでしょうか、また再発していたので、使っていたJavaScript Load Imageっていうライブラリを最新のものにして直しました(ただ、ちゃんと調べていないので、なにか勘違いしているかもしれません)。それから、判別結果に表示される種名はGoogleの検索ページへのリンクにしておきました。それから、PCやスマホの横向き画面では、5位まで表示していた判別結果を7位までとしました。さらにその表示形式の場合のみ、判別に掛かった時間を下に小さく表示するようにもしましたので、ちょっとしたベンチマークとしてお使いください。

1年ほど前ナニゴケを初めてリリースした時に、1年後の目標を「判別できる種の数120・Trainに使用したデータ20,000枚」と書きました。今回のバージョンがその課題の提出期限だと思い、ちょうど苔シーズンでもあるのでそれにも間に合わせたいと結構がんばったつもりです(ばたばたしていて、少し遅れましたが…)。でも、「Trainに使用したデータ20,000枚」はだいたい達成しましたが、「判別できる種の数120」にはぜんぜん届きませんでしたね。ごめんなさい。まあ少しだけ言い訳させてもらうと、やっぱり終盤のコロナが痛かった… 一番最後にバスに乗って苔の写真を撮りに行ったのは、去年の年末だったようで、その後は行動範囲が大幅に制限されてしまいました。今年に入ってから、私はまだ一度もタマゴケを見ていないのですが(！)、そんな春を過ごすことになるとは年始の頃には想像もできなかった… ただ、そのかわり徒歩圏内の身近な苔たちと向き合う良い時間になったのも事実です。半年前の自分が聞いたらびっくりしそうな、いくつもの発見がありました。探せばあるんですよ。ほんとにね…

一応、今回のアップデートで、いろいろ気になっていた細かい部分は作り終えました。気分的には、一段落です。ここから先は、もうただひたすらに学習データを増やしていくだけだと思っているので、やらないといけないことがはっきりしてずいぶんと気が楽になりました。

ナニゴケにはかなりの時間を割いてしまい、もうすでにCOSUMIに掛けた時間を超えちゃったんじゃないかと思っているのですが、なんか、やればやるほどゴールが遠くなるような感覚があって、じゃあなぜそうなるのかというと、自分で勝手にゴールを遠ざけているからなんですよね。一番最初に蘚苔類をやってみようと思いついた時(本当に遠い昔のことみたい…)に考えていたゴールは、もうとっくに通り過ぎているような気がします。別に自分が後ろに後退しているわけじゃない。まあ、いつか納得いくものができるんでしょうが、どうせならできるだけ早めのほうがいいなとは思います。

white shadeを強くしようと、時間のある時に少し手を動かしてはいたのですが、なかなかなかなか強くなりません。もう、真面目に探索しないと、レベル6は難しいですかね？ で、なかなかなかなか強くならないのがつまらないので、今回はwhite shadeを利用したベンチマークテストを作ってみました。

囲碁ベンチマーク – 囲碁ブラウザゲーム COSUMI
https://www.cosumi.net/benchmark.html

ひたすらwhite shadeに手を打たせて、速度を測るというやつです。もちろん、こんなのはまともなベンチマークテストではなく、ただのネタにしかすぎませんので、真面目に使おうとはしないでくださいね。

今現在は、white shadeとの対局はレベル4までしかできませんが、今回のベンチマークはレベル5相当の強さになっています。手元のPython版での計測では、13路盤でGNU Go Level 10に、勝率95.2%、平均42.6目勝つぐらいなのですが、地たくさん勝つ割には、勝率が低くて、なんか安定性がないですね。めいいっぱいの設定にしても、勝率は98%に届かない感じ。でも、この強さでも対局できるように、ここらで一度、対局ページの方も後日アップデートしておきます。

このベンチマーク、私のiPhone 8だと速くて4手/秒ぐらい、GTX 1060(ブラウザが使ってくれているみたい)が載っているPC+google chromeで速くて10手/秒ぐらいになります。それだけ速いのならば、もう少したくさん考えさせてもいいのかもしれませんが、私のクソコードで、ユーザのバッテリーを無駄に消費することになるのは、どうも気が咎めるんですよね…(笑) もうしばらく、シンプルな形で強くならないか、探ってみます。

今回のこのプロダクトを、味気ないベンチマークに飽きた囲碁クラスタに贈ります。とんでもない手も多いですが、そこも含めてお楽しみください。後、これから寒さが厳しくなっていって、スマホをカイロ代わりにしたくなった時にも便利にお使いいただけると思いますので、ぜひお試しください(笑)。

[追記 2020/9/18]
少し書くのが遅くなりましたが、コウの扱いがおかしい時があったのを修正したVer. 1.1にアップデートしました。打つ手は以前のバージョンと同じではありませんが、ベンチマーク結果は基本的に比較可能です。

[追記 2020/12/13]
現在のwhite shadeの対局ゲームとほぼ同じ中身の、Ver. 2.0にアップデートしました。強さはレベル5.8ってぐらいで、全体的に自然な着手になっていると思います。ベンチマークテストの性格上、気軽に上げることができなかったTensorFlow.jsのバージョンも、かなり古いものから最新のにしてあります。ベンチマーク結果については、同じ環境でなら以前のバージョンとほぼ同じぐらいの数字が出るように調整しておきましたが、基本的に比較不可です。ご注意ください。

[追記 2022/4/23]
TensorFlow.jsを最新のバージョンに上げて、囲碁ベンチマークのバージョンをVer. 3.0とします。それ以外の変更はなにもありません。ベンチマーク結果については、当然、以前のバージョンとは比較不可です。全然ちゃんと調べていませんが、ほんのり速くなったような、なってないようなですね。

COSUMIのwhite shadeは、思考エンジン自体はクライアントサイドで動いているので、今までもオフラインでも対局することができたのですが、そもそもオフラインだとウェブページにアクセスして開くことができなかったので、あまり意味はありませんでした。それを、今まで一度でもオンラインの時にwhite shadeのページにアクセスしたことがあれば、次に開こうとした時に、それが仮にオフラインであっても、ちゃんとページが開けて対局もできるようにしました。

white shade – 囲碁ブラウザゲーム COSUMI
https://www.cosumi.net/whiteshade.html

自分で書いててもどういうことだよって感じで、なんだかとても摩訶不思議なのですが、そういうことができるみたいです。時代の進歩って本当に凄いですね。スマホのホーム画面にwhite shadeのページのアイコンを出しておけば、もうほとんどネイティブアプリと同じように使えます。

私は、Service Workerとか言われても、もうよくわかりませんので、今回はUpUpというライブラリをありがたく使わせてもらいました。ひとつだけ注意点として、オフラインでは対局のリプレイは見れませんので、そこだけはご容赦ください(これは今となっては、まあまあ面倒なんです…)。

今後は、空の旅のお供に、もしくは秘境においてのエクストリーム囲碁の対局相手として(笑)、white shadeをぜひご活用ください。

このブログ記事は、以前書いた記事の続きです。よろしければ、そちらもどうぞ。

Keras/TensorFlowでDNNな囲碁の評価関数を作ってみる
http://www.perfectsky.net/blog/?p=350

Keras/TensorFlowでDNNな囲碁の評価関数を作ってみる その2
http://www.perfectsky.net/blog/?p=380

囲碁の思考エンジンを作ってみる
http://www.perfectsky.net/blog/?p=389

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

以前から作っていた囲碁思考エンジン「white shade」を、JavaScriptに書き直してブラウザで打てるようにしてみました。COSUMIのクライアントサイド版です。

white shade – 囲碁ブラウザゲーム COSUMI
https://www.cosumi.net/whiteshade.html

今現在は9路盤しかできませんが、強さはレベル1からレベル4まで選択できるようになっています。それぞれのレベルでの強さは、一応、通常版のとできるだけ合わせましたが、通常版を手元で再現するのがちょっとめんどくさくて、なかなか完璧にはいっていません。一応、クライアントサイド版では、レベル1はGNU GoのLevel 7に勝率60%、レベル4はFuego1.1の7000playoutに勝率50%、それ以外のレベルは、1レベル違いの自己対戦の勝率が同じになるようにしていきます(これでまあだいたい通常版と同じです)。最終的には、通常版にも無いレベル7ぐらいまで行きたいですね。まだやれることはたくさんあるので、それぐらいはなんとかなりそうな気はしています。現状は、目一杯の設定で、だいたいレベル4.5ぐらい。GNU Goに一局あたり平均16目ぐらい勝てるのですが、それでも勝率は90%を辛うじて超える程度で、100%っていうのはやはりかなり大変そうですね。

レベル1では、4子までの置き碁もできるようにしました。GNU Goにこれをさせると怪しいことになるのでちょっとあれなんですが、white shadeは、どれだけ形勢が悪くても結構自然に打つので、特に問題は無さそうです。今後はもっと大きな碁盤サイズでも対局できるようにしていきますが、8路盤以下は、もうこれで許してください…

JavaScriptのDNNライブラリ(って呼んでいいのかな？)は、TensorFlow.jsを使っています。私も使えたので(笑)、たぶんそんなに難しいものではないです。元々のPython版white shadeも、GTPとかデバッグ用のコードとかもろもろ除けば、実質200行ぐらい(？)のプログラムだったので、JavaScriptに書き直すのも大した手間ではありませんでした。一番たいへんだったのは、先ほどの強さの調整ですね。きれいに弱くするということがこんなに難しいことだとは、本当に思っていませんでした。後、少し心配しているのが、JavaScript版にした時に、NNのモデルのコンバートなんかで弱くなってたりしていないかなんですが、自分が打っている限りでは、大丈夫なように見えます。JavaScript版の強さの計測は、これも今後ちょっと厄介ですね。

簡単にwhite shadeの中身についても、書いておくと、基本的に、左上から右下まで本当に全幅で1手読んでるだけですが、人の手のみを学習したPolicy Networkの出力も少しだけ加味して手を決定していて、あとは、自然に打てるように微調整ですね。レベル4が少し重いかもですが、それ以外のレベルは、ちゃんと動きさえする環境ならば、おそらくサクサクだと思います。で、問題はそのちゃんと動く動作環境なんですが、今現在、iPhone/iPadのiOS系が安定して動かないと思います(後、IEもですがこれはもう本当にどうでもいい。Androidはちょっと分かっていません)。これは結構色々調べたのですが、まず、iPad+Chromeはだめで、Mac+Safariは大丈夫なので、iOSがだめっぽいのですが、NNのモデルを小さいものに変更するとかなり安定するようになるので(ちなみに今現在、Value Networkが92万、Policy Networkが45万パラメータぐらい。本当はもっと大きなNN使いたいぐらいなのに…)、端末が非力なことが単純に問題なのかもしれません。とはいえ、とりあえず動くだけは動いて欲しいのですが… iPhoneで動かない限り、トップページからのリンクもちょっと張れません。これはまた、なんとかします。

今現在、COSUMIは年間のサーバ代(最初に掛かった初期費用は入れず)が130万ぐらい掛かっているのですが、それがこのクライアントサイド版でいつか半分ぐらいにならないかなあと、つい皮算用してしまいます。私は今、車が欲しいんです(笑)。生まれてこのかた、一度も車なんて買ったことないのですが、今猛烈に欲しいんですね。軽でいいんですけど、新車が欲しい(笑)。そのためにも、このサーバ代はなんとかしなければいけません。話変わりますが、なんかネット見ていたら、さくらインターネットからお中元が来たって方がちょくちょくいるのですが、今までに新車のポルシェ一台分ぐらい貢いだ私はもらったことがない！(笑) うー、まだ足らないのかな… おいらもチョコが食べたい。

[追記 2018/9/2]
今回は、white shadeで囲碁の対局をできるようにしたわけですが、いつかは、9路盤以下の悪手指摘機能をこれで置き換えたいですし、もっと言うと、white shade Teach作りたいですね。この場合、teachするのは、囲碁というよりも、white shadeの囲碁に対する気持ちぐらいでしかありませんが(笑)、それでも、初心者の方には、十分有益なような気がします。忙しいので当面の間は無理ですが、またいつかがんばります。

[追記 2019/1/5]
ブラウザがロードするTensorFlow.jsのライブラリのバージョンを上げたら、iOSでもwhite shadeが動くようになったみたいです(やほい！)。ひさしぶりに私も対戦してみましたが、この子、そんなに弱くはないのですが、ときどきとんでもない転び方するので、ちょっと面白いです。ぜひiPhoneで一局打ってみてください。

今現在、9路盤以外でも対局できるように準備していますので、そちらはもうしばらくお待ちください。

このブログでは囲碁の棋譜ビューアとしてGoswfという、Flashのソフトを使っていたのですが、自分でiPadを使っている時にも当然見ることができなくて、さすがにそろそろまずいかなあと思っていました。ところが、じゃあJavaScriptなので何かないかと探しても、意外なことに適当なのがぜんぜん見つからないんですね(最初に探し始めたのは、1年ぐらい前だったような気がする…)。せいぜいちょっとオールドファッションなEidoGoぐらいで、これは9路、13路、19路以外はちゃんと対応していないみたいです。というわけで、時間は掛かりましたが、ようやく見つけたのが今回のWGo.jsです(正確には、WGo.jsを利用したWGo.js Playerで棋譜再生ができます)。

WGo.js – javascript library for game of go
http://wgo.waltheri.net/

SGF Player | WGo.js
http://wgo.waltheri.net/player

こんな感じで表示させることができます。

クリックしないと対局結果が表示されないのは気が利いていますし、コメントに座標が含まれていれば、その座標にマウスオーバーすると、その場所が画面に示されるのは、ちょっとおしゃれです。

以下、簡単に使い方の解説をします。

まず、ファイルをダウンロードしてきます。正式版では、パス(着手放棄)の扱いがおかしかったりするので、こちらから開発版を落としてきたほうが良いと思います(最新の開発版はこれはまたこれで、本当はできるはずの碁石の大きさの変更ができないような気がしますが…)。必要なファイルは、wgo/wgo.min.js、wgo/wgo.player.min.js、wgo/wgo.player.css、wgo/wood1.jpgだけです。単色の碁盤、もしくは自前の碁盤の画像を使う場合は、wood1.jpgも必要ありません。その場合は、後で説明するように、碁盤の設定をしてください。

次に、ファイルをサーバにアップロードして、headタグ内で、wgo.min.js、wgo.player.min.js、wgo.player.cssをロードします。

<script type="text/javascript" src="path/to/wgo.min.js"></script>
<script type="text/javascript" src="path/to/wgo.player.min.js"></script>
<link type="text/css" href="path/to/wgo.player.css" rel="stylesheet" />

CMSなどを利用する場合は、絶対パスの方が良いかもしれません。wood1.jpgはwgo.min.jsと同じところに置いておきます(もしくは、後で説明するように、パスを設定してください)。

最後に、ウェブサイトの棋譜ビューアを表示させたい所に、このように記述します。

<div
style="width:650px"
data-wgo="(;GM[1]FF[4]SZ[9];B[aa];W[bb];B[cc];W[dd];B[])"
>
Sorry, your browser doesn't support WGo.js.
</div>

外部ファイルを読み込むこともできます。

<div
style="width:650px"
data-wgo="path/to/sgf-file.sgf"
>
Sorry, your browser doesn't support WGo.js.
</div>

初手以外を初期局面としたい場合は、このように記述します。

<div
style="width:650px"
data-wgo="(;GM[1]FF[4]SZ[9];B[aa];W[bb];B[cc];W[dd];B[])"
data-wgo-move="3"
>

デフォルトでは、碁盤の画像はwgo.min.jsと同じ場所に置かれているwood1.jpgが使用されますが、それ以外の画像を使いたい場合は、このように記述します。

<div 
style="width:650px"
data-wgo="(;GM[1]FF[4]SZ[9];B[aa];W[bb];B[cc];W[dd];B[])"
data-wgo-board="background:'path/to/image.png'"
>
Sorry, your browser doesn't support WGo.js.
</div>

碁盤を単色にすることもできます。

<div 
style="width:650px"
data-wgo="(;GM[1]FF[4]SZ[9];B[aa];W[bb];B[cc];W[dd];B[])"
data-wgo-board="background:'#bbccbb'"
>
Sorry, your browser doesn't support WGo.js.
</div>

スタイルシートのwidthプロパティで、表示サイズを変更することができます。ただし、レイアウトも変わってしまう時があります(ちゃんと調べてないので、ちょっとよく分かっていません)。

これ以外にも、WGo.jsはかなりいろいろとカスタマイズすることができ、この手のソフトに求められる機能は、ほぼ網羅されている気がします。詳しくは本家サイトで調べてみてください。

WGo.jsは最低でも向こう5年、もしかすると向こう10年、問題なく使い続けることができるソフトだと思います。廃墟(笑)のようになったJavaを使ったウェブサイトとか、もう見たくありません(作られた時はものすごい労力がかかったでしょうに…)。今このタイミングで、Java、Flash、EidoGoからWGo.jsにみんなで移行しませんか？

COSUMIのHTML5版ではjQueryを使用しているのですが、先日正式にリリースされたバージョン2.0に切り替えました。

オンライン囲碁ゲーム COSUMI
http://www.cosumi.net/

jQueryは現在、1.9系と2.0系という2つの系列があって、1.9系が通常版で2.0系がIE6～8に非対応なスペシャル版的な位置付けになっているんですが、COSUMIのHTML5版はもともとIE6～8では動かなかったので、割り切って2.0系を使い始めることにしました。たぶん、なんの問題も発生しないと思いますが、なにかあってもすぐに直せると思います。

このブログ記事で問題にしているiOSのバグは、iOS6.1ですでに修正されています

– – – – – – –

先日公開したCOSUMIのHTML5版には、「iPad3でページをスクロール中に碁盤や碁盤の周りのクリッカブルな所をタップするとその後の動作がおかしくなる」という不具合がありました。私もいまだによく分かっていないところがたくさんあるのですが、原因とそれに対してとった対策を簡単に書いておきたいと思います(このブログ記事には私の勘違いが含まれている可能性が高いです。すべてを鵜呑みにはしないでください)。

この不具合に気づいた時、まず最初に思ったのは、これはフェードイン・フェードアウトが絡んでいるのでは、ということでした。スクロール中のフェードイン・フェードアウトは、描画がたいへんなのではないかなと。しかし、必ずしもそうだと言い切れないような感じだったので、少しネットで検索してみると、こんな情報が見つかりました。

javascript – setInterval pauses in iphone/ipad (mobile Safari) during scrolling – Stack Overflow
http://stackoverflow.com/questions/11177774/setinterval-pauses-in-iphone-ipad-mobile-safari-during-scrolling

おおこれだと思いました。jQueryの.fadeIn()/.fadeOut()はJavaScriptのsetIntervalを使っているようです。しかしちょっと腑に落ちないのは、なぜタイマーが止まっただけで、その後の動作がおかしくなるのかです。再開さえしてくれれば問題無いはずですが… そこで、もう少し調べてみると、こちらのブログのコメント欄に、ちょっと気になることが書いてありました。

There is one more bug I haven't seen anybody writing about. If a touch event causes a setTimeout, but that same touch event causes scrolling, that timer will never fire.

More information and a workaround here: https://gist.github.com/3755461

あれっ？ なんかおかしい… 「止まる」のではなく「発火しない」と書いてあります。そしてリンク先のios6-timers.jsをCOSUMIのに試させてもらうと、不具合が完全に起こらなくなりました。

簡単なサンプルページを用意してみました。モバイル端末から試してみてください。Startボタンをタップすると、赤と青の四角が右に動きます。赤い方はJavaScriptのsetIntervalを使っていて、青い方はCSSのtransitionを使ってのアニメーションです。

http://www.perfectsky.net/misc/20121002.html

<!DOCTYPE HTML>
<html>
<head>
<meta name="viewport" content="width=640px">
<title>iOS6 Timer Test</title>

<style>
div{
  position : absolute;
  left     : 20px;
  width    : 100px;
  height   : 100px;
}
#div1{
  background-color : #ee4444;
  top              : 20px;
}
#div2{
  background-color : #6666bb;
  top              : 140px;
}
button{
  display   : block;
  margin    : 300px auto 0;
  font-size : 200%;
}
</style>

<script src="http://code.jquery.com/jquery-1.8.2.min.js"></script>
<script>
$(function(){

  var pos = 20;

  $("#div2").css("transition", "left 10s linear");

  $("button").on((window.ontouchstart === null) ? "touchstart" : "mousedown",
                 function () {

                   $(this).remove();

                   var timerId = setInterval(
                     function(){
                       $("#div1").css("left", ++pos);
                       if(pos >= 520){
                         clearInterval(timerId);
                       }
                     }, 20);

                   $("#div2").css("left", "520px");

                 });
});
</script>

</head>
<body>
<div id="div1"></div>
<div id="div2"></div>
<button type="button">Start</button>
</body>
</html>

まず最初は、Startボタンをタップして赤と青の四角が右に動き始めたらそこでページをスクロール(ピンチイン/ピンチアウトでもいいです)してみてください。たぶん、両方の四角が停止すると思います。そしてスクロールしていた指を離すとまた動き始めます。これは、iOSやAndoidではよく知られた挙動のようです。

そして次は、まずページをスクロールし、その指を離さないままStartボタンを押して、最後にスクロールしていた指を離してみてください。私の持っているiOS6のiPad3では(SafariでもChromeでも)、下の青い四角は動きだしますが、上の赤い四角は動き始めません。これはどうやらiOS6のバグのようです。そして先ほどのios6-timers.jsを使うとこの不具合は起きません。

肝心のCOSUMIへの対策ですが、最初はjquery.animate-enhanced pluginを使えばそれだけで直るかなと思ったのですが、よくは調べてませんがそれではうまくいかなかったので、最終的にはjQueryの.fadeIn()/.fadeOut()をすべて.show()/.hide()に書き換えることによって解決しました。他にも書き換えないといけないところがありそうでしたが、とりあえずCOSUMIの場合は、すべてjQueryの.fadeIn()/.fadeOut()に絡んでいたようです。ios6-timers.jsの使用は副作用があってもいやなのでちょっと控えました。将来的にはできればもうちょっとましな対策をしたいと思いますが、とりあえず今はこれでいきます。

今回のバグは、ページのスクロール中という限られた状態でしか発生しないためか、当初は全くといっていいほど情報がありませんでしたが、すこしずつ気づいた人がでてきたようです。

javascript – iOS 6 safari, setInterval doesn't get fired – Stack Overflow
http://stackoverflow.com/questions/12683510/ios-6-safari-setinterval-doesnt-get-fired

setTimeout while scrolling in iOS 6 doesn’t work, works in iOS 5 – Google グループ
https://groups.google.com/forum/?fromgroups=#!topic/phonegap/3Xe_M79qHEM

[追記 2013/1/29]
今回のiOSのバグは、iOS6.1で修正されたようです。COSUMIの方もまた今度元に戻しておきます。

[追記 2013/2/7]
.fadeIn()/.fadeOut()に戻しておきました。たったこれだけのことで、リッチな感じになるんですよね。