val it: α → α = fun

ふと SkipList を作ってみた。最初は pure scheme for Gauche で書いて、試してみたらあまりにも遅かったので、ついカッとなって Gauche の拡張モジュールとして実装した。

通常の整数比較とし、ランダムな数値をキーとして挿入し、10000回ほどランダムなキーで探索するという単純なベンチマークで treemap と比較してみた。比較結果は、

SkipList 1000 ;(time (times size (lambda (x) (skip-list-put! list-bench (mt-random-int … ; real 0.032 ; user 0.020 ; sys 0.010 ;(time (times 10000 (lambda a (skip-list-get list-bench (mt-random-integ … ; real 0.386 ; user 0.280 ; sys 0.110 10000 ;(time (times size (lambda (x) (skip-list-put! list-bench (mt-random-int … ; real 0.556 ; user 0.390 ; sys 0.160 ;(time (times 10000 (lambda a (skip-list-get list-bench (mt-random-integ … ; real 0.587 ; user 0.420 ; sys 0.160

treemap
1000
;(time (times size (lambda (x) (tree-map-put! tree-bench (mt-random-inte ...
; real   0.021
; user   0.010
; sys    0.010
;(time (times 10000 (lambda a (tree-map-get tree-bench (mt-random-intege ...
; real   0.252
; user   0.190
; sys    0.070
10000
;(time (times size (lambda (x) (tree-map-put! tree-bench (mt-random-inte ...
; real   0.333
; user   0.240
; sys    0.090
;(time (times 10000 (lambda a (tree-map-get tree-bench (mt-random-intege ...
; real   0.358
; user   0.250
; sys    0.100

こんな感じ(数値はリストの要素数)。うーむ、ちっと遅いな。ちなみにベンチマークを測ってみたところ、

Profiler statistics (total 27 samples, 0.27 seconds) num time/ total Name calls call(ms) samples ---------------------------------------------------+------+-------+----------- (#f #f) 518310 0.0004 19( 70%) (#f #f) 218019 0.0003 7( 26%) call-macro-expander 86 0.1163 1( 4%) (make-skip-list #f) 695229 0.0000 0( 0%) < 695229 0.0000 0( 0%) = 332868 0.0000 0( 0%)

となっているのだが、この (#f #f) てのはなんだろう。 static な C 関数のなか、とかかなあ。 (make-skip-list #f) は、 make-skip-list 内で作っている比較関数か。

ところで、 SkipList って乱数を使うとされているのだけど、実際には乱数の乱雑さは実はそんなに重要じゃないということがわかった。統計的にうまくバラけてくれればいい。実際、さいしょは math.mt-random を使っていたのだが、上のベンチマークはそうじゃないが、性能劣化はない(むしろ乱数生成よりずっと単純な処理なので性能は微増しているかも)。

昨夜の地震では本棚がぐらぐら揺れてちょっと怖かった。まあ倒れませんでしたけど。寝てるときに倒れたりすると、頭に向かって倒れかかるようなレイアウトなのはちょっとやばいですね。寝るときの向きを変えようかと思いました。

その前につっかえ棒か。

Radium Software の「メールは伝わったつもりのメディア」という話が面白い。内容的には、さもありなんという内容ではあるけれど。ただ結論として出てくる56%という率の妥当性はわからない。むしろ 56 / 78 は 0.71 くらいなので、「メールだと伝わったと思っていることの3割くらいは伝わってない」という風に解釈して読んだ。それにしても確信度はメールでも音声でも同じくらいなのだね。

ところで、ブログメディアということを喧伝したい場合、この辺のロスはまったく馬鹿にできないと思うんだが(ブログなどでの情報伝達の場合、確信度と実際の正答率のギャップはメールよりはるかに大きいだろう)、その辺で調査をすると面白いかもね。

RSS リーダとしては Livedoor Reader を使ってきたのだが、ふと思い出して Google Reader を使ってみた。まあ、使える。使い勝手は微妙に違うが、それほど大きな優劣は感じない。どちらを常用しても大差ない感じ。なのでしばらく Google Reader で生活してみよう。ま、わたしが登録しているのはたかだか60件くらいだから、何でも同じだということかもしれないケド。

今のところの雑感。

キーバインド。 Google Reader のキーバインドはあまり練れてないと思う。 GMail に似ているようでわりといきあたりばったりな雰囲気が漂っている。ただ、このキーバインドは、 LDR のような特定のフィードのものを読んでいくというスタイルではなく、いくつかのフィードを横断的に読むスタイルを含意しているように思える。でも、 Shift キーを使うのはなー。

ピン。 LDR のピンはなかなかの発明で、この快適さは Google Reader にはない。けれども、まあ、 s でスターをつけて gs すれば、それほど手間でもないか。

検索。 Google Reader は当然検索ができる(昔はできなかった(!)けど)。 LDR の検索はフィード名の検索でエントリの検索じゃないが、 Google Reader は過去のエントリの内容も含めて検索ができる。また、 Google Reader は過去のフィードを読むのが簡単だ。 LDR では基本的に、いちどでも閲覧した記事を読むことはできなくて、どこかに消えてしまう(よね)。

全体的な雰囲気として、 Google Reader は各エントリをじっくり読み、時に読み返すというスタイルを支援している。 LDR は最新のフィードを心地良く読むことに注力している。そういうスタイルの差があるといえるのかな。

あと Google Reader は携帯電話対応がいいらしいけど、うーん、携帯では使ってないからなー。

終了。

磯光雄インタビューで聞き手をつとめました。私は何にもできなかったが磯さんがたいへん愉快な人だったので結果的にはとても面白い話になったのではないかと思います。