単体分割のモンテカルロで宇宙を出せるのか
LHC が動きだしたからか、ちょっと物理への興味が高くなってきている。
そのへんの関係のページをみてたら次のブログエントリをみつけた。
物理のおたふく はっしー帝國 - 自己組織化する量子宇宙
『4次元時空をつくり出すというか，4次元時空がひとりでに生まれる理論が登場した。「因果的動的単体分割」だ。』
ちょっとまえに偶然本屋で立ち読みしたやつだった。日経サイエンスのページはここ。
自己組織化する量子宇宙
自己組織化する量子宇宙
J. アンビョルン（ニールス・ボーア研究所）／J. ユルキウェイッツ（ヤギェウォ大学）／R. ロル（ユトレヒト大学）http://www.nikkei-science.com/page/magazine/0810/200810_022.html
アンビョルンさんたちの論文は、まだ大学にいるころにコロキウムで発表させてもらった(2002 年ころだろうか)。残念ながら、日経サイエンスの記事をみても新しい結果がでているようにはおもえなかったが、新しい論文がでているかは不明。時間を決め打ちした時空の単体分割で、モンテカルロする、っていうはなしだったとおもう。発表のときに、たしかコメントとして、「ひとつ fine-tune がはいっている、なので R^2 gravity じゃないか」というようなことを教えてもらった。物質をなにもいれずに重力だけの理論で、潰れたり、拡散していっちゃったりせずに、ちゃんと膨らんだ空間が実現できるとはちょっと思えない。
もし新しい論文がでているのならばおもしろそうなのでながめてみたいなぁ。ところで、物理屋さんで、論文の紹介するようなブログ書いてるひといないのかなぁ? 米国の素粒子屋にはいるみたいだが、趣味でながめている程度なので英語はつらい。
まだ読んでないがひとまずリンクだけ。
昔読んだもの。2001 年だな。
[hep-th/0105267] Dynamically Triangulating Lorentzian Quantum Gravity
Fruitful ideas on how to quantize gravity are few and far between. In this paper, we give a complete description of a recently introduced non-perturbative gravitational path integral whose continuum limit has already been investigated extensively in d less than 4, with promising results. It is based on a simplicial regularization of Lorentzian space-times and, most importantly, possesses a well-defined, non-perturbative Wick rotation.
こっちがアンビョルンさんで arXiv を検索して一番あたらしい論文。
[0807.4481] The Nonperturbative Quantum de Sitter Universe
A candidate theory of quantum gravity which achieves this goal without invoking exotic ingredients or excessive fine-tuning is based on the nonperturbative and background-independent technique of Causal Dynamical Triangulations. We demonstrate in detail how in this approach a macroscopic de Sitter universe, accompanied by small quantum fluctuations, emerges from the full gravitational path integral, and how the effective action determining its dynamics can be reconstructed uniquely from Monte Carlo data.
Greenplum が MapReduce をサポートとのこと
Greenplum MapReduce - Bringing Next-Generation Analytics Technology to the Enterprise
Greenplum MapReduce enables programmers to run analytics against petabyte-scale datasets stored in and outside of the Greenplum Database.Greenplum MapReduce は、Greenplum DB の中または外にある、ペタバイトスケールのデータに対する、分析を可能にする。
ホワイトペーパーをパラっとみたところ、以下の 2 点が目にとまった。
- map フェーズは、Greenplum の各ノード(データベースエンジン)の上で実行されるため、パラレルI/O の恩恵を受けることが出来る
- Perl と Python で map / reduce の処理を書くことが出来る
サンプルコードも性能数値もまだ出ていないのでちょっと具体的に掴めないかんじ。ま、まだアーリーアクセスらしいしそんなもんか。
Greenplum は、穏やかなトランザクションで、データサイズが大きいという領域ではあるが、トランザクションまで含めた RDBMS ということで気になる存在だ。
bif 一覧
同じく、 cooldaemon さんの結果で、
lists モジュール、自前の関数、リスト内包表記の速度比較 - cooldaemonの備忘録
検証コードを繰り返し実行した所、lists:reverse/1 の方が、自前の関数より早い事の方が多かった。
というものがある。これも根っこがきになる。
まずは、bif.tab をみてみる。erlang/otp の src を解凍したところの、 erts/emulator/bean/bif.tab に BIF の一覧がある。そこで、lists を探すと、以下が記述されてる。
bif lists:member/2 bif 'erl.lang.list':is_element/2 ebif_list_is_element_2 lists_member_2 bif lists:reverse/2 bif 'erl.lang.list':reverse/2 ebif_list_reverse_2 lists_reverse_2 bif lists:keymember/3 bif 'erl.lang.list.keylist':is_element/3 ebif_keylist_is_element_3 lists_keymember_3 bif lists:keysearch/3 bif 'erl.lang.list.keylist':search/3 ebif_keylist_search_3 lists_keysearch_3
lists:reverse/2 ってなに?
lists
reverse(List1, Tail) -> List2Returns a list with the top level elements in List1 in reverse order, with the tail Tail appended. For example:
> lists:reverse([1, 2, 3, 4], [a, b, c]).
[4,3,2,1,a,b,c]
http://www.erlang.org/doc/man/lists.html
ふうむ、不思議な感じのする(なぜこれを独立したライブラリとしたのか分からない)関数だ。
一方、lists:reverse/1 の定義はこちら。
reverse([] = L) -> L; reverse([_] = L) -> L; reverse([A, B]) -> [B, A]; reverse([A, B | L]) -> lists:reverse(L, [B, A]).
3 要素以上であれば、lists:reverse/2 に投げている。ということで、BIF が効いているということで納得。
# BIF の中身の C のコードはまだ理解できる気がしない :-
lists:foreach、 関数渡し
cooldaemon さんが Erlang の lists モジュールの性能検証してくれている。どんどんコードを書いて進んでいくところは見習いたいが、なかなか手がついていかんなぁ。
ひとつ、lists:foreach について、気になった。
lists モジュール、自前の関数、リスト内包表記の速度比較 - cooldaemonの備忘録
foreach末尾再帰できなくても自前の関数の方が早い・・・コードの書き方が悪いのかな？
lists:foreach/2 を使ったからといって、可読性が劇的に上がるわけでもないので、lists:foreach/2 は使うの止めよう。
lists:foreach を見てみると、このようになっている。
foreach(F, [Hd|Tail]) -> F(Hd), foreach(F, Tail); foreach(F, []) when is_function(F, 1) -> ok.
最初に、一番当たるだろう末尾再帰がきて、なんでか分からんけど、空リストのときには、is_function でガードしている。
このコードで、自前末尾再帰と差が出るのが不思議だったので、cooldaemon さんのコードにひとつテストを足してみる。 # gist つかいやすいね
http://gist.github.com/6484
自前末尾再帰の foreach 相当のコードで、関数を渡す版を付けた。すると、当然ながら(?)、 lists:foreach と同じ程度の数字が出てくる。ということは、lists:foreach というよりは、関数を渡す、または、渡された関数の実行という部分で、なんかしらオーバーヘッドがある、と思うほうが良さそう。
zenbe のメッセージ表示を as is に
userContent.css
div.zenbe_message {
white-space: pre;
font-family: monaco;
}
vmware fusion で、HDD ファイルを 2GB に分割
% /Library/Application\ Support/VMware\ Fusion/vmware-vdiskmanager \ -r allinonefile.vmdk -t 1 diveded2GBfiles.vmdk
vector clocks
たけまる / Algorithm::VectorClocks を作った
Vector Clocks を実装したモジュールを作成しました．このモジュールを
使うと，Vector Clocks の管理や比較を簡単に行うことができます．
http://teahut.sakura.ne.jp/b/2008-02-11-1.html
さっそく作ってる! コメントが出来なかなったので、たいした感想じゃないけどここに書いてみる。
ノードが OS のプロセスと対応すると思っていいのかな? ハコ(筐体)毎に一つのクロックがあるのとプロセス毎にもつのはどっちが良いだろう。プロセス毎に持つと名前を付けるのが結構面倒になるかもなぁ、とちょっと気になってしまいました。
