GMTLeopardからは、小学館の辞書データとWikipediaが追加されて、とっても便利なDictionary.app.たぶん、キーボード使用を前提とした小気味よいインターフェースがいいんだと思う。慣れてしまうと、もう生のWikipediaを使う気はなかなか起きない。なると、なんでもかんでも、同じインターフェースで済ませたくなるもので、そんな時に、こんな検索しにくいページを見たら、「Dictionary.appで検索できて然るべき」と思ってしまうのが自然な流れ。LexiconをDictionary.app用に変換します。テンプレートをコピーしてくる。試しにmakeすると、あっさり辞書が作られる。以下にコピーされ、Dictionary.appから検索できる状態になる。"Done."Done.重要なのは、MyDictionary.xmlファイル。辞書の元となるデータをパースして、XMLファイルを作ってやる。--></d:dictionary>意味はほとんど見た目通り。それぞれの項目は、インデックスと内容のXHTMLで構成される。他の単語を参照する、href=”x-dictionary:r:ID”とかが特徴的か。puffer」という単語に対して、pufferでも検索に引っかかって欲しいので、indexに加えてある。パースしてXMLを吐くコードは、汎用性がないのでここには載せないが、今回は以下のようなLifeを表す図を、rcairoでpng画像に変換もしている。以下の適当な場所に置いておき、普通のHTMLのように、<img>タグを使って埋め込む。installすれば、ユーザ辞書の完成。Compositionを組み込めないか、頑張ってみる。これで、普通のムービーならスタートするのだけど、ライフゲームなので第0世代の画像を渡してやらないといけない。APIが用意されていて、publishしたパラメータを設定できるようになっている。文字列しか設定できないようだ。画像はどうやって渡すのだろう。Downloaderというパッチを使うらしい。Downloaderは指定されたURLの画像をImageとして出力するパッチ。"fullpath.png");こんな感じになるのかな。先生、こちらにできあがったものが用意してあります。EMBEDに勝手に付け加えたimage属性から、フルパスを取得する仕組みに。文中のSpaceはCompositionというか、Universeというか。document.getElementsByTagName("HEAD")[0].appendChild(tag);</script>というコードも、<d:entry>内に埋め込むように。これで「生きた」LifeLexiconが完成。CREDITをどこかに入れないと配布できないらしいので、欲しい人には直接送ります。Manualをこれで。Composerに手を出してみた。Language?)用意されていて、後者二つは最近流行?のベクトル指向な言語。以前から、GPUのシェーダ言語でライフゲームを書いて見たかったので、テーマはライフゲームに決定。KOF2007の懇親会で、小波先生、池上さんとライフゲームの話題で盛り上がったのも理由。Languageのコードは以下。画像のある一点の色を決めるコードを書けば、あとは勝手にベクトル化してくれているはず。(たぶん、ベクトル化のために)普通のif文は使えないので、compare関数を使う。1);}それから、1step前の状態が必要なので、JavaScriptで以下のようなPatchも作成。フレームをまたがって値を保持するには、ObjectかMathのプロパティに値を入れておけばよい。result;}後は適当にPatchを組み合わせていけば、完成。Remoteでコントロールしたり、スクリーンセーバにしたり、1フレームで3step進めたりしなければ、もうちょっと単純になる。ライフゲームのルールについてはWikipediaを参照していただくとして、自分の周囲9マスから次の状態を決定する、という非常にローカルで単純なルールから、あまりに複雑で大域的な発展が繰り広げられる様は、宇宙や生命といった壮大なものを連想させる。ライフゲーマー必見!ものすごい勢いで宇宙を浸食するmaxと、MITが開発したグライダーガンの、宇宙を賭けた闘い。GMTCGALすごいの一言。幾何計算に関するアルゴリズムライブラリ。あこがれの、あんなアルゴリズム、こんなアルゴリズムがいっぱい。GMT画像から直線っぽいところを検出する手法。集合が得られるが、この(x,y)→(a,b)への変換がHough変換。(他にもsin,cosを使った表記法はあるけど本質は同じだろう)xy平面上の一点はHough変換により、a,b上では直線となる。この変換を、全ての点(直線の候補点)について行い、a,b平面上で積算する。ところで、Hough平面(ていうのかな?)上の一点はxy平面ではある直線を表すので、ある直線上の点が多ければ、Hough平面上のある点における積算値は高い値を示すはず。Hough平面上の積算値の高い点を、直線っぽい、とみなしてxy平面上の直線に戻してあげる、という仕組み。円の場合も同様に処理できるが、こちらはパラメータの数が多いので、積算する空間が三次元になってしまう。