Oddwit

前回の続きです。

コペンハーゲン解釈 vs EPR

測定していない事象はあくまで不定であり、それを考えることには意味が無いとするのがコペンハーゲン的解釈。それに対し、アインシュタイン・ポドルスキー・ローゼンは通称EPR呼ばれる思考実験を提唱し、反証しようとした。

EPR実験では、正反対の方向へ飛び出す一対の粒子を考える。すると一方の粒子について位置や運動量などを測定することで、もう一方の粒子に関しては何の影響も与えること無く情報を得られることになる。つまり測定と独立した絶対的な現実が存在するはずだという主張だ。だがコペンハーゲン派代表のボーアはそうではないと言った。

ジレンマの誕生だ。アインシュタイン説を取るとある定まった現実が存在することになり、ボーア説を取ると何らかの方法で瞬間的に情報が伝達されていることになる。両方、あまり好ましくない。

ボームの「隠れた変数」説

ボームは、測定している事物には、我々の知らない秘密の「隠された」特性があるのではないかと言った。例えば二重スリット実験で言うと、光は実際に粒子であり、どちらか片方のスリットを通る。その際、光子はガイドウェーブというものに導かれる。その上で光子の初期状態に微妙なばらつきがあるため、結果として干渉模様が生まれるという。

だがこの説はあまり広く受け入れられなかった。まず、ガイドウェーブが光子に道筋を教える方法を説明するために量子ポテンシャルと言う不可解な新しい概念が必要であること。次に、光子は力の作用を受けないのにどうやって道筋を変えるのかが上手く説明されないこと。さらに、ガイドウェーブは必然的に非局所的であり、装置のあらゆる部分からの必要な情報を持っていなければいけないこと。

ベルの定理

ベルは同時に二つのEPR実験を行った際のそれぞれの粒子の状態を変数としたある代数式を掲げた。もし隠れた変数によって情報が瞬間的に伝達されるのなら、その式は-2〜+2の値を取るはずだった。しかし実験的には、最大で2√2までの値を取りうることが分かり（アスペが行ったこの実験はこの本で解説するには難しすぎるらしい）、かくして隠れた変数説は失脚した。コペンハーゲン解釈は妥当性を保ったわけだ。

残された可能性

隠れた変数による潜在的な現実という説が倒れたいま、残された考え方は三つに分けられる。
・ボーアが正しく、観測するまでは不定なのかもしれない
・瞬間的に伝わる影響力があるのかもしれない
・観測機同士が互いに影響を及ぼしているのかもしれない。

ただし後者ふたつは、分からない部分を別の分からない部分へと押しやっただけ。一方コペンハーゲン解釈は据わりが悪いが理論としては簡潔だ。

続きます。

最終回

ところで、このブログをRSSリーダーで見るとまったく改行されずに表示されていたようですが、修正しました。少なくともGoogle Readerでは正しく表示されるはず。

カブロボグリッドをとりあえず動かしてみた。

昨日まとめたBOINCの仕様の実感を何となくつかめた気がする。

今はこの研究室マシンでカブロボクライアントが走っているが、なにやら気に食わんらしい。Project Communication Failed?? うむぅ。なぜ？もしかして仕事がないんだろうか。ワークユニット生成はした覚えがない。どこでどういう風に行うものなのかはまだ理解していない。

BOINCのドキュメント首っ引きで進めているが、この順番で読めば間違いない、という風には書かれていないので必要な情報だけスキャンしようとするとやや難しい。片っ端から読まなければいけないかもしれない。

これからすること：

• ワークユニットとリザルト生成にまつわるBOINCの仕様を理解する
• カブロボグリッドにおけるワークユニットの構成方法を理解する
• クライアントによる出力がどこにどう記録されているのかを理解する
• ライアンが残したユーティリティスクリプトを読んで理解する

研究室にあるグリッド関連の書籍がかなり貧弱なので図書館に行ってみたが、やはりあまりエキサイティングな文献は見つからなかった。ついでに言えば 工学 部の文献室にも初めて行ってみたのだが、こちらもDoors検索すると状態が「研究室」の物ばかりで、結局余りよい書籍や文献は手に入らずじまいである。 まぁ今はまだ自分のやるべきことがハッキリしていないから論文を読んでも仕方がない（というよりも論文の探しようがない）のだが。

適 当に検索してみるとスケジューリングやらなにやらで色々と分散・並列コンピューティングに関する資料はヒットするのだが、そのうちどこまでの面倒を BOINCが見てくれているのかは知っておく必要がある。さすがに二週間でBOINC自体に手をつけるのは難しい。自分が触るべきところをハッキリさせる のが今週の目標か。

ネットワーク情報システム研究室のスタートアップとして、去年同じ研究室にいたRyanがやっていたカブロボグリッドにとりあえず着手することになりました。

これはRyanによる卒論のまとめおよびメモです。

アブスト

システムトレードとは、投資を行う際に裁量を排し、売買ルールに従って取引をする方法。株取引アルゴリズムとパラメータの組み合わせ（「パラメータAとBの除がCになれば売る」など）。この探索空間は膨大。これまでは人間の感覚によるヒューリスティックな選択がされてきた。
本研究では売買ルールの全探索のためにカブロボグリッドを構築し、実装と評価をした。

１．背景と目的

システムトレードの気運が高まっている。例えばトレードサイエンス株式会社では2006年から仮想市場でのカブロボコンテストを実施しているし、野村総研では大口の注文をシステムトレードを介して証券取引所に取り次ぐシステムを開発、運用している。取引アルゴリズムはルールとパラメータの組み合わせによるが、ルール同士を組み合わせることも可能であるため、探索空間は膨大であり、これまでブルートフォースなアプローチは取られてこなかった。

そこで、グリッドを利用してアルゴリズムの探索を行うシステムを提案、実装、評価する。そのためには
１）探索アプリケーションのグリッド化
２）全体を管理するグリッドの構築
が必要であり、本研究では２を行う。

２．要素技術

Ａ）BOINC
汎用グリッドフレームワーク。TANPAKU、SETI@HOME、BBC Climate Change Experimentなどで採用。クライアント数百万台での大規模運用も可能。

・サーバ
クライアントの状態把握、データの受け渡し、ワークユニットとリザルトの管理。
うち前者二つは提供され、後者二つは自前で用意する。

・ワークユニット
実行すべき計算を表現したルール。リザルトを抽象化したもの。
常に十分な数のワークユニットがサーバ上に存在するように、ワークユニットジェネレータにより定期的に生成される。

・リザルト
ひとつの計算を表現したもの。必ずしも計算後の結果ではない。
ひとつのワークユニットからは必ず同じリザルトが生まれるが、冗長化のためにデフォルトで五つのリザルトが生成される。

・クライアント
コアクライアント（BOINCが提供）とクライアントアプリケーション（プロジェクトが提供）。
コアクライアントは各々のマシンで直接実行できるネイティブコード形式でなければいけない。

Ｂ）カブロボ
トレードサイエンス株式会社が配布している取引シミュレーションソフトの一部。KaburoboSDK(Java)またはKaburoboBuilderLiteでカブロボを開発。2004～2006の株価データでのシミュレーションが可能。

３．カブロボグリッドの構築

サーバからクライアントへ取引ルールを渡し、配布されているシミュレーション機能で評価させる。クライアントはカブロボSDKとそのラッパー。

・株価データは本来単一でいいのだが、カブロボのインスタンスによってロックされるため、一台のクライアントマシン内で並行して走らせるために各リザルトに株価データを添付することにした。
・カブロボはシミュレーション結果を標準出力にしか出してくれないため、ファイルへリダイレクトする機構を実装。
・閉じた環境であるためリザルトの冗長度を5から2に変更。
・ワークユニットジェネレータを作成。

４．評価と考察

ネットワークとBOINCによる二つのオーバーヘッドが考えられるが、今回検証したのはBOINCのほうのみ。評価はサーバ1台、クライアント1台。結果、１リザルトあたりの処理時間はカブロボ単独148s、BOINC利用時179sとなった。（全体の18%）

５．今後の課題

ワークユニットジェネレータを改良し、より多くのワークユニットを生成できるようにする。
シミュレーションで使える銘柄を多くし、リアリティを増す。
以上。

感想など

・関連研究を明らかにしたい。
・BOINCのその他の利用例と基本的なグリッドのセオリーを調べたい。
・ヒューリスティックなアルゴリズムを利用することも検討。
・ルール同士の組み合わせが可能だというが、それなら探索空間は無限？
・もし有限ならばその大きさの概算がほしい。
・株価データを何回も送るのは通信がしんどい？そうでもない？
・今回生成できたワークユニットの数が少なかった理由は何？
・Low latencyの方向へ進めるならいじるのはワークユニットジェネレータあたりか。
・もっとクライアント数を増やして試したい。ってLow latencyするなら必然的に増やさねば。
・ということはスケジューリングや分配方法に頭をひねるべき
・そこへきてBOINCはどれほど世話を焼いてくれるのか？
・グリッドを使ったほうが人間ヒューリスティックよりもよいアルゴリズムが見つかるというのが論点ならば、計算速度だけではなく出てきた結果の有効性によって評価するべき。
・たとえばSETI@HOMEなら全世界の人間が参加しても困ることはないが、全世界の人間がこれをやりだしたらどないしまんねんという根本的な疑問。そもそもにおいて一部の人だけが使うから良いという技術？ただの個人的な倫理問題だが重要かも…。
・それにしても研究室にグリッド関連の書籍が少ない。

あらすじ：pacoを使えばlinuxでmake installしたアプリを管理でき、ファイルの一覧を見たり削除したりできます。そんなpacoのインストールの仕方と使い方です。

make installしたアプリをアンインストールする方法は、ネットを探してみるといくつか提案されているのが見つかります。
・make uninstallする（そんなのがついてるお行儀のよいアプリは少数派）
・make installのログを取っておく（出力されない場合あり。めんどくさい）
・rpmやdebパッケージを作っておく（かなりめんどくさい）
・makefileを読んで手で消す（いやいや。時給が出るならやってもよいが）

そこで登場するのがpaco。

pacoを使うと、make installした際にどこにどんなファイルが入ったのかを一つ残らずログしてくれます。ログはGUIで確認することができ、さらには一発でキレイにアンインストールすることも可能です。

pacoの入手

http://paco.sf.net/

インストール

普通に./configure, make, make installします。
Paco自体のインストールは管理できないの？と思ったんですが、ちゃんとできました。make installの直後に

$ make logme

することで、paco自体のファイルリストがログされます。

使い方

通常sudo make installするところで、代わりに

$ sudo paco -D make install

を実行するだけです。

-Dは現在のディレクトリ名をPaco上での管理名として使うオプション。-pで名前を指定してもいいですが、毎回考えるのも面倒なので僕は-Dを使っています。その他のオプションなどはpaco –helpで確認できます。

管理

Ubuntuの場合はアプリケーション→システムツール→Package OrganizerにGUIでの管理ツールが登録されます（ターミナルからはgpacoで起動）。あとはそれぞれのパッケージをダブルクリックすればファイル一覧の表示や削除が可能です。

ちなみに削除ボタンがグレーアウトされているのはおそらく権限が無いからですので、スーパーユーザで実行しなおしてみて下さい（sudo gpaco）。

make install以外の管理

pacoはファイルシステムへ書き込みを行うシステムコールを直にモニタするらしいので、インストール時に出た標準出力などとは関係なく正確なファイル一覧が取得できます。

それならば、と思ってこんなことをしてみたら上手くいきました。

rubygems-1.1.1$ sudo paco -p rubygems ruby setup.rb

~$ sudo paco -p active_youtube gem install active_youtube

~$ sudo paco -p test touch test

要するにどんなコマンドにでもかませてしまえばOKのようです。gemならもともとアンインストールが簡単ですからあまり意味はありませんが、把握していたいような気分ならぜひ。

ちなみに、似たような目的のソフトウェアに「CheckInstall」というものがあるようです。こちらはソースパッケージからrpmやdebを簡単に作成できるそうな。