卒研のレベルを高める手がかり（その３）

　複数のスマートフォン（Androidなど）やPCの間でデータを共有したい場面は非常に多いです。卒研でもそうでしょう。そのための具体的な方法はいくつかありますが、その中でも、key-value型のデータベースを使うためのTinyWebDBがあり、非常に便利で高性能です。これは、MIT App Inventor for Androidに備わっています。最近では、その仲間のThunkableやAppyBuiledrでももちろん使えます。

　従来のTinyWebDBは、下図のとおり、クラウド（Google App Engineなど）の上のPythonで作られていました。手軽に使えて非常に良いのですが、場合によっては、いつもクラウドへアクセスするのではなく、ローカルネットワーク（LAN）の中でそれを使いたいことも多いです。例えば、研究室内でデモする場合など、Androidアプリケーションは変更せずに、TinyWebDBのサーバアドレスだけ変更して、それができればいいですね。

ローカルネットでもTinyWebDBをつかう！

　それを実現するためのPHPプログラムを作った人がいて、早速それを利用させていただきました。上図のように、１台のAndroidでWebサーバを動かします。その際、PHPも使える必要があります。このWebサーバに、このPHPプログラム（TinyWebDB）を格納すればよいのです。Android用のWebサーバプログラム（PHP付き）は、Googleプレイに有料、無料のものが多数ありますので、それを利用できます。

　ところで、このTinyWebBDですが、"Web"の付かないTinyDBというのも、同じ構造ですが、（ネットワークを使わない）Android単体内部では使えます。これも必要に応じて使えます。Key-Value型（Tag-Value型ということもある）は、単純ですが、以下のように、Valueとしてリストも使えます。それによって、TinyDBの中に構造を持たせることができます。それによりさらに用途が広がります。

Key-Value型だが、Valueをリストにすることで構造を持たせることも可能

卒研のレベルを高める手がかり：Multi-level Models In NetLogo 6（その２）

先の記事で、NetLogo 6のMulti-Levelモデリングについて書きました。
http://sparse-dense.blogspot.jp/2017/02/multi-level-models-in-netlogo-6.html

これまでは、それぞれ２つの独立したmodel（NetLogoプログラム）であったものを、有機的、階層的に連結して、そられをマルチスレッドで同時実行させるものでした。さらに、注目すべき、下記の短い論文に出会いました。

［文献１］Arthur Hjorth, et al.: LevelSpace: Constructing Models and

Explanations across Levels, Proc. of the Constructionism 2016, pp.362-363, 2016.

その中にある図を引用させていただきます。

NetLogoの３つのmodelの連携（[文献１]より引用、説明加筆）

２ページの論文なので、各modelの詳細は書かれていませんが、すばらしいアイディアであることはすぐに分かりました。以下のような内容です。model-1とmodel-3のソースコードは公開されていますが、model-2（ニューラルネットワーク）の詳細は書かれていませんので、これを自分で設計、実装すれば理解が深まり、実力がつくでしょう。

◎ model-1のみ：狼と羊の個体数のダイナミクス

羊は草を食べ、狼は羊を食べる。羊も狼も一定のエネルギーを得るとある確率で子を増やす。また、ある条件で死ぬ。草もある確率で再生する。この単独モデルでは、これらの確率は乱数で決めていた。

◎ mode-3を追加：温室効果ガスによる気温変動

このモデルを使って、model-1での草の再生の具合を、環境変動（気温変化）に依存させる。

◎ model-2を追加：ニューラルネットワーク

このモデルを、狼の（羊にも適用できるが）脳の働きを簡単に模倣するのに使用する。すなわち、model-1単独の場合は、狼の進むべき方向は乱数で決めていたが、各狼にそれぞれ簡単なニューラルネットワークを割り当てることで、環境（近隣の羊や草の情報）に応じて進む方向を決める。つまり、狼に頭脳を与える。ニューラルネットワークの辺の重みは子に継承させるが、子は、次第に僅かにそれらの重みを変えることで、より環境に適応できるだろう。

◎ メインのmode-1に、上記の２つのモデルmodel-2, model-3を連結させて、それらをマルチスレッドで同時に動かす。これによって、よりリアリティのあるシミュレーションとなっていくだろう。

来た！Java TensorFlow！

　Googleの著名な人工知能開発環境（ライブラリ）TensorFlowが、昨日（2017-2-15）正式版Version1となりました。

http://forest.watch.impress.co.jp/docs/news/1044528.html

　今まではベータ版だったのですね。その際に、特に注目されたのが、Java APIが公開されたこと。ただし、Javaの場合は安定性の保証がない実験的実装となっていますが。これまでは、主にPythonでした。Pythonは非常に使いやすいのではありますが、学生諸君が（私もですが）また、新たにPython言語を覚えないといけないので、ちょっとしんどい。でも、もちろんやる気でここまできてはいました。

　ここへ来てJavaでTensorFlowが使えるとなれば、これは私にとっては一大事。取組み戦略も変えないといけないくらいの出来事です。すぐに、そのTensorFlow Java APIを使う例題を動かすことにしました。多少トラブルがあったものの、Mac Power Bookで動かして、感触を掴むことができました。

　その例題は、（どれだけの画像を学習させたは不明ですが）とにかく、与えられた画像を1,000種に分類するものです。つまり、与えた画像に映っているものが、1,000種類のもののうち、どれに一番近いかを判定します。下図が実行結果例です。

上段：ニューラルネットワークの画像→判定はcrane（鶴）。そうも見えます。
下段：ICカードリーダーの写真：→判定はmouse。そうも見えます。

　このJava例題は、学習済みのCNN（畳込みニューラルネットワーク）を使って、何でも与えられた写真（画像）を判定するものです。比較的簡単な例題として作られたものなので、それほど高性能ではありませんが、今後Javaでやるための糸口を得られたことが大きい。もちろん、今後、学習するためのCNN自体も、このTensorFlow Java APIで作ります。

卒研のレベルを高める手がかり：Multi-level Models In NetLogo 6

　今年度の卒研は終わった。その内容はまだまだ不十分だろう。そのレベルを高めるとは何を意味するだろうか。探求意欲の乏しさ、着想の未熟、現実性や実用性からの乖離、それらから脱却したい。できるところから改善を進める。普段からそのことを想い巡らしている必要があるだろう。

　エージェント指向モデリング環境NetLogoの最新版Version 6のある機能が気に入っている。Multi-level Models In NetLogo 6である。従来は、特定の自然現象や物理現象ごとに、それぞれモデル（プログラム）を作っていた。それで非常に高いレベルのシミュレーションはできた。今回、さらに、個々のモデルを連結して、ひとつの統合モデルにする機能ができたのである。しかも、それらを階層的に結合できる。それらは同時に（マルチスレッドで）実行される。

　例えば、あるモデルに含まれるある機能（サブモデル）は大まかに（マクロに）作成して動かす。別途、そのサブモデルを具体的に実現するモデルを作る。その２つを階層的に結合して一つのモデルとして、全体を同時に動かすのである。

　何か、卒研のレベルを高めるためのヒントを与えられた気がする。具体例を見てみよう。NetLogoシステムに含まれるモデルライブラリのうちから、次の２つに着目する。（両者は互いに独立に、特に関連性なく開発されたモデルである。）

■Wolf Sheep Predation（羊の群れに対するオオカミの補食圧）

　草原には草が生える。羊はそれを食べて子を産む。狼は羊を食べて子を産む。それらは何れもある確率で生ずる。草が枯れてしまえば、羊が居なくなり、狼も死滅する。狼が増えすぎてもいけない。羊と狼の個体数の変動（ダイナミクス）を観察する。

 

■Climate Change（温室効果ガスによる気温変動）

　ＣＯ2は、太陽からの照射エネルギーは通過させるが、地面からの輻射エネルギーは通過させないので、大気の温度は上昇する。これは、ＣＯ2の greenhouse effect （温室効果）と言われる。

Wolf Sheep Predation（羊の群れに対するオオカミの補食圧）

Climate Change（温室効果ガスによる気温変動）

　この両者を結合して一つのモデルにするのである。すなわち、Wolf Sheep Predationでの草の生え方を、Climate Changeによる温度変化に基づいて、より精密に決められる。このようにして、モデルを階層的に作って統合することで、現実性の高いモデルを作るのである。この例では、地球温暖化の問題を取り込んだことで、より現実的な課題に向かうきっかけになるだろう。

FirebaseをMIT App Inventorから利用する

　「互いに、相手の居場所が変わったら、自動的に自分の端末の地図にそれが表示される」という地図アプリを作りたいとします。

　相手の緯度経度がwebデータベースに格納されるとして、適当な時にそれをチェックしてその位置情報を得て、自分のマップ上に表示すればよい。しかし、それではちょっと不満が残ります。下図のように、相手の居場所が変わったら、自動的に直ちに、自分の端末にそれを示したい！そこで、Firebaseの登場です！実際、以下の図１と図２のプログラムがそれを実現するための全体です。

【プログラム設計】互いに、相手の位置が更新されたら自分の画面に直ちに表示
自分の位置送信ボタンはあるが、相手の「位置受信ボタン」は無い！

　リアルタイムのプッシュ型と言っていいのでしょうか。FirebaseというKey-Value型のWebデータベースがあり、色々な用途があるようです。特にこれが、MIT App Inventor for Android（および、ThunkableやAppyBuilderでももちろん）が使えるようになっています。大いに活用したいものです。

　App Inventorには、これまでもKey-Value型のWebデータベースとして、TinyWebDBが有名でした。これとの大きな違いは、Firebaseでは、特定のKey（タグ）に対するValue（値）が（誰かによって）変更された場合、アプリケーション側で自動的にそれを関知してその変更値を受け取ることができる！ことです。すなわち、アプリケーションが自分でデータベースを見に行って、変更があるかどうか調べる必要がありません。それによってプログラムは簡単になります。以下にその部分を示します。

（図１）データベースの値の変更を自動的に受け取る処理部

これを使って、「相手の位置が変わったら、自動的にマップのその位置にマーカーを表示する」例が以下に解説されています。分かりやすくて有用です。

Using Firebase in a real app – “Here I AM!” GPS Demo app

http://appinventor.pevest.com/?p=1387

　それを参考に、さらに簡単なプログラムを以下に示します。図１と図２がこのアプリの全てです！

（図２）現在位置をFirebaseへ登録する部分

（注１）相手の位置を受信するボタンはありません！（自動受信です。）

（注２）本当は、自分の位置の送信ボタンも不要です。しかし、そうすると、バッテリーの消費が著しくなりますので、送信ボタンを設置しています。

（注３）とりあえず、２人用に作りましたが、Firebaseへ格納する際に、タグに個人ID情報を加えれば、３人以上もできます。

Developer of the Future!

　何かのコンテストに入選して、その賞品が届くとなれば、誰でも（年齢を問わず）ワクワクして待ちますね。その入選については、下記のとおり、本学KAITニュースと情報工学科ブログでも紹介していただきました。

http://www.kait.jp/news/1336.html
http://blog.cs.kanagawa-it.ac.jp/2017/01/y.html

　このAndroidスマホアプリのコンテスト、学会発表などとはちがう、誰にも親しめる雰囲気があります。ちょっとくつろげる、ちょっと心暖まる要素も含まれています。これにふさわしい賞品が米国から届きました！先方は、"a fun holiday gift, it's pretty cool!"と言っていました。

アメリカから郵送されてきた賞品

　帽子と「Top Developer 2016」というステッカーが入っていました。少し前に、この賞品の写真が別途送られて来ていました。これを家人に見せたところ、「トランプ大統領の帽子に似てない？」と言われました。「う〜ん、似てるかもしれないが刺繍（ししゅう）が違うでしょ。Make KAIT Great Againじゃなく、Developer of the Futureとなっている！」

ヘッドの文字部を拡大

ステッカーの裏側

　Developer of the Future（未来の開発者）、よい響きです。学生のみなさんにこの言葉を贈りたい！