SORACOMは海外に進出したのですね
ニュースを読んでいたら、SORACOMが海外に進出した話が書かれていたので、一時マイブームだったIOT関連でいくつか記事を書いたことを思い出しました。
SORACOMのドングル+SIMを買ったりしたのですが、今は全く使っていません。WIFIにしか繋がらないため、情報をインターネットにアップできる場所が限定され、あまり使えないと思ったことが一因です。
ちなみに、IOTがマイブームの時に、マイコン、定電圧電源、コンデンサ、抵抗、配線、LEDなど、電子小物関連の部品をたくさん買ってしまったのですが、全く使っておらず、ゴミに近い状態になっています。勿体ない買い物をしてしまいました。とはいえ、中国から電子部品を買うと、驚くほど安く買えるので、すべて合わせても1万円も行きませんが...
それにしても、このSORACOMは、結局、SOFTBANKに買われてしまうのではないかと思っていたのですが、まだ、単独の企業として頑張っているようですね。
tensorflowを試すなら、やはりLinuxが良い？ [12/3更新]
当方のサイトで2番目にアクセスが多い記事は下記であることが分かりました。ただ、Windows上のDockerではGPUを使えなかったので、結局、1週間ぐらいでDockerを捨て、Ubuntuをデュアルブートでインストールしています。その後、Windowsを使う時間よりも、Ubuntuを使う時間の方が長くなってしまいました。それでも、その時書いた記事が今でもアクセスされているのは、なんだか懐かしい気がしました。
DockerでGPUが使えないのは、基盤として使っているOracle VirtualBoxでGPUを使えないからです。これが解決すると、かなり便利になるのですが...
訂正[2016/12/3]
先ほど見たら、WindowsでもGPUが使えるTensorflowがリリースされた模様です。
https://www.tensorflow.org/versions/r0.12/get_started/os_setup.html#pip-installation-on-windows
むしろ、Windowsの方が、簡単にインストールできるように見えます。
https://www.tensorflow.org/versions/r0.12/get_started/os_setup.html#pip-installation
For Windows users, you can also install the GPU version of the binary with: bash $ pip install tensorflow-gpu Unfortunately, this command is not yet available for Linux or Mac GPU binaries due to their sizes exceeding the Pypi limit.
スクレイピング関連記事は人気が無くて残念
Android Studio関連記事(ご参考）
久しぶりに、本ブログのアクセス解析を見たら、下記が最多アクセス記事でした。
実は、上記の記事には続きがあるので、興味のある方は、下記をアクセスすると、Android関連の記事を纏めて確認できます。ご参考まで。
ちなみに、2か月ぐらい前までは、下記の記事が一番アクセスされていました。なお、Oracle Java Certified Programmer Silverを取得した際は、満点を目指して勉強していたので、かなり詳しくなりましたが、あまりにもJavaのプログラムを書いていないため、細かいところは忘れてしまいそうです。人の話す言語と同じで、プログラミング言語も、使わないとだめですね。
itsukara.hateblo.jp
世の中の関心も、JavaからAndroid Studioに移ったということでしょうか...
ちなみに、最近使っているプログラム言語は、Pythonばかりです。
昨日は、たまたま、VLOOKUPを多用して異様に時間が掛かるEXCELシートの高速化にチャレンジしました。再計算に数時間も掛かるEXCELシートを高速化し、10秒位になりました。ただ、高速化前と異なる結果が出ることがあり、見直しが必要そうです。
それにしても、今回の高速化で「遅いものを速くすること」が、とても好きであることに、改めて気が付きました。、
マウスコンピュータPC：電源スイッチ修理で25,000円？？
久しぶりに、本ブログのアクセス解析を見たら、下記の記事が意外とアクセスされていることに気が付きました。
そこで、マウスコンピューターのサポートサイトで、電源が入らない場合の診断を試したところ、「PCケース(フロントスイッチ部)の故障が考えられます。」との診断結果がちゃんと書かれていました。これはこれで良かったと思います。
以前に電話した際は、「そのような原因だったことはない」と言われたので、「FAQに、電源スイッチの不良のも必ず書くべき」と強く念を押した甲斐があったという気がします。
ただ、そのあとに書かれている下記の記載が問題です。
診断ID ： MC01000008
概算修理費用 ： \25,000-（税別）
電源スイッチの交換だけなのに、なぜ費用が25,000円
【DRL, Montezuma】GCPの無料試用期間がほぼ終了
GCPの無料試用期間がほぼ終了したので、最後の学習結果を下記に置きました。
正確には、残り日数が6日で、残りクレジットが420円となりました。上記学習結果を見ると、gcp10だけは今後も訪問部屋が増える可能性があるので、これだけを残し、残りの仮想サーバー7台を全て削除しました。これで、仮想サーバーが残り1台だけになったので、6日間は使えると思います*1。
ちなみに、gcp10～gcp70は、全て、thread毎の多様性を持たせて学習を安定させるために、pseudo-rewardを計算するときの指数をthread毎に少し変えてみました(2.0 + thread番号(0〜7)*0.7)。
しかし、gcp20, gcp30は、途中で急激にSCOREが0点になって、その後も回復していません。結局、多様性の効果がどの程度あったのか分かりませんでした。
統計的に有意な結果は示すには、条件を変えてもっと沢山試す必要があると思います。また、thread毎の環境も、もっと変えて試した方がよいかもしれません。例えば、上記記載の指数の変化の幅をもっと大きくするとか、pseudo-rewardの係数であるbetaも変化させるとか。
ただ、今とのころ、実験を試すプラットフォームが無くなったので、当面は、別のことに注力しようと思います。誰か、ITリソースを湯水のように提供できる人/団体がいらっしゃるとありがたいのですが...
そういえば、以前に、OpenAIから$250分のAWSクレジットを貰えそうだという話を書きましたが、OpenAIとのインタビューの話に紛れて、結局貰っていません。ただ、インタビューに関しては、サンフランシスコまでインタビューを受けに行く旅費と2日分の宿泊費を頂けることになりました。これに向け、現在のスライドよりも詳しい説明資料の作成に注力する予定です。
【DRL, Montezuma】スライドを再更新
相変わらず続けているMontezuma's Revengeの実験ですが、pseudo-countを各部屋ごとに持つように変更したところ、到達部屋が１つ増えましたので(ROOM 20、DeepMindの論文には未記載)、スライドを更新しました(p.16、p.18、p.20を微修正。p.19を追加)。なお、p.19記載のように、１回の学習(50M steps)で、かなり広い範囲の部屋に到達することができました。
日本語版
DeepMind論文(2016/6) 「Unifying Count-Based Exploration and Intrinsic Motivation 」 記載のPseudo-count を用いたMontezuma's Revenge の評価 from 孝好 飯塚
www.slideshare.net補足
実は、参考にしているDeepMindのpseudo-countの論文が11/7に更新されました。新たな情報として、DeepMindの実験では、pseudo-countに使うゲーム画像のpixelの値を3bit(最大値が7)で表現しているということが書かれていました。ちなみに、当方は7ビット(最大値が127)で表現していました。そこで、3bit(最大値が7)〜6bit(最大値が63)でどうなるかを試したのですが、残念ながら、良い結果は全く得られませんでした(このサイトのmontezuma-p 〜 montezuma-sの00index.html参照)。
そこで、pseudo-countからpseudo-rewardを計算する式の指数(pseudo-reward = 1/power(pseudo-count, p)でのpの値)を少し変えて試しましたが(montezuma-t)、これも今ひとつ。
そこで、以前から懸案であった「pseudo-count」を各部屋毎に持たせるようにしたところ、非常に良い結果が得られました。このページの一番最後のグラフを参照頂くと分かりますが、訪問部屋は[ 0 1 2 3 4 5 6 7 8 9 10 11 12 18 19 20]とかなり多く、平均得点も1700点ぐらい出ています。
ただ、点数が上がり始めたのが40M stepsからです。他の実験では、30M stepsで諦めてしまったものもあるので、これらも、もっと続ければ高得点に繋がった可能性があります。
高速な実験環境が多数利用できれば、１週間ぐらいで試せると思うですが、これが無いので、この結果が出るまでに、１ヶ月ぐらい掛かってしましました。Google Cloud Platformの無料枠を最大限に使い、4CPUの仮想サーバを8台使って試しているので、結構リソースは活用しているつもりですが、やはり、個人でできることには、かなり限界がありますね。
補足3
実験の学習グラフを見ると、平均スコアが途中で完全に０になったりと、かなり不安定なことが分かります。この不安定性を除去できれば、もっと良い点数が出ると思います。ただ、この原因調査は不十分な状況です。
不安定性の調査の一環として、下記2つの仮設を立てて、ちょっとだけ試したところ、下記1つ目は誤っているように見えました。2つ目は、なんとなく、効果が出ているように見えます。ただ、本来は、数十回以上の実験を行わないと、統計的な差は示せないと思います。これも、リソースが無いため、勘に頼らざるを得ない状況です。
- 【仮説1】各スレッド毎に別々にpseudo-countを持っているのに、そこでの経験を同じネットワークに学習させるので、学習環境とネットワークの間で矛盾が生じている可能性がある。もしかしたら、pseudo-countをthread間で共用すれば良いかも。
- 【仮説2】上記とは逆で、学習が進んで点数が上がると、全てのthreadでpseudo-countが似た値になるため、A3Cで重要となる「thread間での多様性」が失われるため、学習が不安定になるのでは？ もしかしたら、各thread毎に、パラメーターをもっと変えれば、学習が安定するかも。
上記を確認するために行ったことを少し説明します。
montezuma-v0を見ると、gcp10, gcp30, gcp40の学習曲線が、一度ピークに達した後、急激に0になっていることが分かります。そこで、上記1つ目を試すために、gcp10とgcp40に対し、ピークになった時点での学習データのthread0のpseudo-countを、全てのthreadでロードして再度学習させてみました。この結果は、montezuma-v1のgcp10とgcp40です。これを見ると、結局、ピークの後で急激に0になっています(gcp40は、一度値が回復するものの、直ぐに0になっている)。
これに対し、gcp30では、逆に、thread毎の多様性を持たせるため、pseudo-rewardを計算するときの指数をthread毎に少し変えてみました(2.0 + thread番号(0〜7)*0.7)。たまたまの可能性も高いのですが、gcp30は、点数が一度0になっても、その後で回復しているように見えます。やはり、thread間で多様性が合ったほうが良いのかも。(全くもって曖昧な話ばかりで申し訳ありません...)
上記から、単なる直感ではありますが、thread間で多様性があったほうが良いのではないかと思い、現在、試しているところです。ただ、既に書きましたように、使っているリソースであるGoogle Cloud Platformの無料試用期間は後１〜２日なので、学習曲線が上向くまで試せるか、微妙な状況です。
