emacs のoctave modeの拡張は一通り完了しました。あとは、不具合を見る段階です。これでよければ、extend-octave-mod.el としてちゃんと公開する版にしようとおもう。どのoctaveでも利用は可能だと思うけど、心配なのは、infoモードに関するところですね。うちの環境(openSuSE 11.1 x8664)ではoctaveを導入と同時にinfoファイルがインストールされるけど、cygwinなどではどうかしらんので。infoパスさえ通せば可能ではないかと思う。
これで、octave scriptを書く際の支援機能が強力になってます。*.mを作成しながら、inferior-octave-mode (M-x run-octave)のバッファ移動をせずに、実行させることができるし、最近公開された補完機能も取り入れたことや、infoヘルプも簡単に参照できるようになったので、imaximaやessと操作性を近くなってます。
都合があって、octaveでプログラミングを始めたけど、同じ数学系の言語としてRと較べたときに柔軟性がまったくちがうという印象をもちましたね。Rのほうが断然上かな。その場限りのプログラムを組むならoctaveは簡単なんですが、柔軟性を考えたときに、関数の中に関数を埋め込めなかったり、クロージャや関数を引き数に取れなかたりするのは障害になりますね。関数を引数に取る場合はfevalを使えば良いけど、lambda関数系に較べて柔軟ではないですね。
octaveも3になってが無名関数が使えるようになったみたいです。これを使うと関数内で関数を定義することは可能になったみたいですね。
こちらで作っていたソースをMercurial リポジトリとして公開しはじめました。
ibm系のソースはibm/exampleにてあります。browse -> 適当なソースを選んで rawで生ソースが取り出せます。(Mercurialのパッケージを利用するともっと簡単に取り扱えますが、ここでは割愛します。windows ならばTortoiseHgを、その他はMercurialの配布サイトにあるものなどを使えばいいです。)
miscにあるのは現在rubyで作ったものになってます。game.rb … 囚人のジレンマゲームスクリプト かな。
このサイトもwordpressで作ってたけど、アップデートが面倒なので、作りを再構築しようと考えておりますが、その一環ですね当初はgitを使ってソースの管理を考えていたけど、xreaへの導入がmerrcurialのほうが簡単であったために、merrcurialの導入にしたんですね。
IBMをcommon lispでということを幾つかやってたけど、可視化で悩んで置いてあります。当初はLTKというtcl/tkのライブラリを利用したものを活用することを考えましたが、1次元セルオートマトンを作てみて感じたのは可視化では厳しかった(作りが悪かった？)です。Common lispの部分は最適化すればそこそこ速いです(作りかたによってはC言語並になるので) OpenGL系にすれば速くはなるけど、使うライブラリがOS毎に制限があったり面倒なことがありますので。実際にUbuntuからOpenSUSEに乗り換えたらライブラリも変更したくらいなんですね。
あれこれ考えていますがね。いまはclojureという言語で検討していますね。これ を見てためそうと思ったんですね。アリのIBMでnetlogoやstarlogoにもサンプルで付いているものと似てる。starlogo系との速さの違いはなんとも言えませんね。というのはClojureもCommon Lispと同じ動的な言語だし、しかも、マルチプロセッサに比較的簡単に対応させられる。そして型宣言を利用して最適化も可能だってことからですね。だから、IBMに試す価値はあるかと思う。Java上だということだから、単一CPUならCommon Lisp(SBCL)より遅いかなというチョットしたプログラムを作成したときの印象はあります。その反面Processing言語のライブラリを使えるということがあったりして、可視化の表現力はかなりあるんではないか？という印象ももっています。また、歴史が浅い(2006年くらいに作られ始めた言語)ですが、最近の注目は海外では大きいみたいです。これはマルチプロセッサに対応させる方法の評判からみたいですね。
Clojureは別サイト にまとめているのでそちらでどうぞ。日本語の資料がないので、資料をつくって公開していかないとだめだと思ってますね。国内で利用しているのはまだ二桁いるかいないかくらいじゃないかと思う。Common LispなどLisp系になれていれば、基本は同じだから学習には時間はかからないという印象もありますね。
残ってる連続時間のシミュレーションのページも早く作成しなければと思ってるけど、ソースが複雑になって理解しがたいものにしない工夫をしていかないとと思っています。離散時間のシミュレーションでも表現型を導入しただけで複雑になったので、それ以上となるとどこまで簡単に表現ができるのか?悩んでいますね。
まだ、離散時間の2種系あたりを作って公開しておく方がソースが読み易く簡単なものになりそうな印象も持っていますね。さてどうするか?
行き着く先はデータベースの活用になってきますが、そこまでは当面公開しないと思う。
現在少しSQLを特訓しています。 考えていることに対して必要性を感じたからなんですけどね。SQLはデータを操作するだけならば、さほど難しくはなさそうです。今週中に簡単な事はマスターして、common lispの中から操作してみたいと考えています。(clsqlを利用します。)おそらく、データ構造を作成する際の工夫が大変なんだなぁ。と言う印象ですね。最初の取り決めがダメなものでしたら、最後までパフォーマンスに響きますから。僕が行おうとしているのはシンプルなことなんで、入門レベルでも何とかなるのではないかと考えています。データが1億となれば厳しそうだろうから、SQLにデータを流し込むことはどこまで耐えられるのか?見極めなきゃいけない問題は残ってます。
適当な本を探していましたが、O’REILLYの「初めてのSQL」をやってるところですね。
優先順位付キューのアルゴリズムなんですが、バイナリヒープのほうを当面は利用します。フィボナッチヒープの方が速くなるかなと思って作ってみたものの、既に作っていたバイナリヒープによる優先順位付キューより遅いものになってしまったからです。複雑さとメモリを食いすぎたことによる遅さみたいなのでまた詰められそうな気がするけど、最大で１００万個くらいのノードを持つキューを想定しているので、この利用方法ならば、バイナリヒープでも極端に遅いとは思わなかったので取り合えずこのまんまです。僕の実装はC++のSTLにある優先順位付キューに比べれば遅いので、それより速くできる方法はないか模索したいですね。上手なフィボナッチヒープの実装を知らないからなぁ。よく言われている双方向リストを使ったものにはしてみたんですがね。
ページの方で個体ベースモデルの内容を一つ一つまとめてるけど、genotype-phonotype mapを導入した単純な個体ベースモデルのソースを作成中です。考え方その物は単純なんだけど、難易度がそれまでより格段に上がってしまう。それゆえに初めてcommon lispに触れた人にはちょいと辛い内容になってしまう。common lisp初心者にも理解できるうまい方法がないか模索ですね。
この位になってくるとちょっとした関数もテスト関数を作って、おかしな動作をしないか一つ一つ吟味しなくてはいけないくらいの少し複雑なものも含まれてきていますね。そのテスト関数も一工夫もふた工夫もいるので頭を使いますね。これは、遺伝を入れると単為生殖じゃなくて、1対のペアをランダムに選ぶということをしなくてはいけないからですね。その結果がランダムになってるのか?すべてをちゃんとペアを作るのか?ということを吟味させなくてはいけないからです。このgenophenoあたりからはcommon lispのリスト、シンボルの取扱いの便利さやハッシュ関数が用意されてることのありがたさをすごく実感できるところになってきます。この辺はLL言語(ruby,pythonなど)でも速度的なことは別にして、速く作れそうな気がしますよ。
離散時間のモデルでも少し複雑になるので、連続時間になるとどうなるだろうね。さらに複雑になるなぁ。考え方自体はさほど難しくはないです。でも、この辺の取扱いを理解していれば様々な問題に個体ベースモデルを当てはめることもできてくるので、どうしても数式で扱い切れない範囲の理屈に対してアプローチする方法を入手できますよ。:-)さらに多種系まであつかえるともっと複雑な問題に対してアルゴリズムで勝負することができるんちゃいますかね。多種系のgenophenoあたりまでは取扱いを方はある程度整理できてますけど、実際に作ってどこに問題があるか確かめないとね。絵に描いた餅は当てにならないしね。
以前に公開していたものを全面的に改訂して公開しなおすように手はずを進めています。
知ってる方がいるかどうかしらないけど、僕の言語歴は主にC -> C++ -> Common Lispです。Common Lispは最初とっつきにくいところがあったけど、すごく馴染みやすいです。とっつきにくさというのはC/C++から始めたことは少なからず影響していますね。でも、数学的な素養があって、どのプログラミング言語も扱ったことがないならLisp系は理解しやすいですね。構造は単純だけど柔軟性は他の言語ではおいつかないものだからです。速さもそこそこ期待できますね。エキスパートレベルならCと同等まで速くできると断言していますが僕にはまだまだそこまではなってません。
そして、REPLという一見インタープリタにみえる環境の中でその場でコンパイルしてプログラムが使えるというのも大変扱いやすいものなんですね。それで他はあまり触らなくなったです。
ただ、空間構造を扱う際にはヴィジュアル的なものは標準のライブラリだけでは難しくって、別のライブラリを使うということ。そして、情報源が限られていることがIBMを作るときには大きな問題でしょうかね。
連続時間のシミュレーションなら優先順位付キューをつかうし、遺伝型を扱うならハッシュ関数をつかったほうがいいしというアルゴリズムの選択もあります。C++のSTLなら両方（もしくは優先順位付キューのみ）はあるし、Boostライブラリにハッシュまで用意されてるから実現は可能だと思うけど、C++のほうが複雑なものを扱うときは本質的な部分（シミュレーションの中核）じゃなくて、その周辺の部分のプログラムの作成に大変時間を要すことがあったりしますから、効率はあまりいいとは思ってないんですよね。(ちなみにcommon lispでは優先順位付キューだけは自前で用意していますし、自分の実装したものは改良の予知はあるかもしれないと思ってる。)
C++とcommon Lispでの柔軟性の違いはC++がまずは型ありきから一般性に向かったのに対して、Common Lispは一般性から型を後でつけるという方向になっていることが影響している。だから C++は同じ関数で違う型のものに必要とあらば大量生産することになるからでしょう。（簡単にできる方法はあるのかもしれないけど。）ここが僕がC++で柔軟性を追求する時に泥沼を感じるの点なんでしょう。Common Lispでかりに同じような場合は関数を作るマクロを使えばこの辺の型宣言で同じ関数を複数作るみたいなのはさほど乱雑にならないようです。広げていこうとすることと絞っていこうとすることでどちらが楽かって事と同じですね。
速さと取扱いやすさでcommon lisp中心に扱ってるって所です。速さにこだわらなければ、既にhash関数が用意されてるrubyやpython, schemeでもいいと思う。この二つの言語はまったくプログラムを作ったことがない人が最初にやる言語で末永く付き合える言語としても向いているといわれてるし、確かにそう思うところはありますね。速さと柔軟性なら間違いなくcommon lispだと思う。C++も柔軟性があるけどジェネリックなプログラムにすればするほど周辺部分でややこしくなってしまう副作用を持っていますね。これは型宣言ありきな点と基本的なシンタックスが複雑過ぎるからだと思ってる。
ということで！？individual based model の作成をもっとも基礎的なところから遺伝型＝表現型マッピングを含めた部分までつくりかたを示していきましょう。多種系や空間構造をとりあつかわないけど、余裕があればそこまで示してみたい。さらに、空間構造を取り扱う際に高速化もできますのでその方法もしめせばいいかな。事前に周辺情報をもたせることで計算量を減らしましょうって話なんですけどね。
Common Lispとindividual Based Modelで有名といえば、ボイドでしょうかね。あれはComon Lispの祖先に当たるZeta Lispで記述されています。ボイドというのは鳥の群れの動きをシミュレートしたもので単純な法則から群れの動きを再現できているということで有名なシミュレーションですね。現在ではJavaやjavascript!!にも移植されている。