なんちゃってMathematicaを作る - その5 [なんちゃってMathematica]
なかなか本題に入らないけど、今日は始める前に言っておかなければいけないことを思い出したので書いておく。あるオープンソースプロジェクトの超大物の話。
2ちゃんなんかでよく見かけるけど、もちろん別もの。名前のもとは「Software for Algebra and Geometry Experimentation」の略だそうである。これは非常に個性的なProjectで、数式処理、数値計算、グラフィクスを統合した超巨大な科学技術計算環境である。
Mac OS X用のアプリの形になっているのはサイズが実に1.8GBある。半分は追加パッケージのサイズで、以前にここで話題にしたMaximaやRが丸ごと含まれている。
ここの開発方針のところに要約があるけど、ようするにMathematicaやMATLABのオープンソース実装が欲しいけど、0から作るのは大変なので、なるべく労力を使わないでやる方法を選んだということ。それはすなわち
例えば、SageのコードはPythonのシンタクスそのものだし、数式の整形にはMaximaとjsMathを、2次元プロットはMatplotlibを、3次元プロットにはJmolを、というふうにありとあらゆるものを使って構築されている。ある分野に強いライブラリがあればそれが直接呼ばれる。典型的なのは統計計算の分野で、ほとんどの処理はRに渡されているようである。
もし興味があればアプリパッケージの中身の
ところで、Windows版は面白いことにVirtualBoxかVMWareの仮想環境上で走らせるようになっている（Windows版のSageをダウンロードするときに同時にダウンロードするようになっている）。普通のアプリではもっともユーザの多いWindowsにまずポートされるのが普通だけど、Sageに含まれている多くのライブラリがLinux上で開発されていてWindowsへのポートの完成度に大きな開きがあるのが一番の問題らしいが、WindowsのネイティブにしたとたんdllがいっぱいインストールされてぐちゃぐちゃになるのでWindowsユーザにはこの形態が安全であるとは言える。
じゃあ、Sageそのものは何をやってるんだ、と思いがちだけど、実はこれはすごいことで、これだけ広範囲にわたるライブラリはそれぞれ好き勝手なデータ構造を定義していてそれを統一的に扱うことはできない。従ってそれぞれのデータ構造に変換する必要がある。これをPythonのブリッジを作って（既にある場合はそのまま流用して）すべてをPythonのデータ構造として扱っている。
また、特にクロスプラットフォームな開発では非常に重くなるUIは、既存のWebブラウザを使うことでプラットフォーム依存のコードを完全に排除している（Sage本体はレイアウトを作るhttpをブラウザに渡したあと、javascriptでtableを更新するだけみたい）。このためちょうどMathematicaと同じようにKernelとFront endが分離して、Sage本体はネットワーク上のサーバで実行するということができる。
非常に頭のいい方法である。
実際にSageを使いこなすというのは並大抵のことではないが、もしPythonのシンタクスに慣れていればSageのほかに何もいらない、ということにもなる。
さらに僕自身はそういう問題以外に、Sageを使っているとフラストレーションがたまってくる。いくつかの原因があるけど、まず
初めて見たときはインデントでブロックを表すやりかたが面白いと思った。会社に入ったばかりの頃HPのpascalを使いだしてbegin-endでブロックを表しているにもかかわらず、エディタ（USCD Pascalのエディタ）がインデントを強制するようになっていた。それなら見た目がうるさいbegin-endをやめてインデントで表せばいいのに、と思っていたのでPythonのやりかたを知ったときは「ほら、言った通りでしょ」という感じだった。
ところがこれがくせもので、結局見慣れないせいでブロックの範囲がかえってわかりにくかったりする（インデントでは空文が表現できないのに、空文を排除していないとかいうところもちょっとひっかかったりする）。要するに慣れが必要だということ。僕は慣れるほどPythonを使い倒していない。
Pythonのシンタクス以外にも、Sageを使っていてフラストレーションがたまる原因としてなににもまして
Sageのおかげで僕の進む方向がはっきりしたような気がする。
6 Sageについて
この話題をはじめてからMathematicaとMATLABと、オープンソースのOctave、Scilab、REDUCE、Maximaなどをあげてきたけど、ひとつ忘れていたことがある。Sageという比較的新しいProjectがある。2ちゃんなんかでよく見かけるけど、もちろん別もの。名前のもとは「Software for Algebra and Geometry Experimentation」の略だそうである。これは非常に個性的なProjectで、数式処理、数値計算、グラフィクスを統合した超巨大な科学技術計算環境である。
Mac OS X用のアプリの形になっているのはサイズが実に1.8GBある。半分は追加パッケージのサイズで、以前にここで話題にしたMaximaやRが丸ごと含まれている。
ここの開発方針のところに要約があるけど、ようするにMathematicaやMATLABのオープンソース実装が欲しいけど、0から作るのは大変なので、なるべく労力を使わないでやる方法を選んだということ。それはすなわち
- 記述言語に高水準インタプリタであるPythonを使う
- UIにWebブラウザを使う（ノートブックと呼ぶ）
- オープンソースの計算ライブラリを取り込み、全体を統合するインターフェイスを設計する
例えば、SageのコードはPythonのシンタクスそのものだし、数式の整形にはMaximaとjsMathを、2次元プロットはMatplotlibを、3次元プロットにはJmolを、というふうにありとあらゆるものを使って構築されている。ある分野に強いライブラリがあればそれが直接呼ばれる。典型的なのは統計計算の分野で、ほとんどの処理はRに渡されているようである。
もし興味があればアプリパッケージの中身の
Sage-4.7.2-OSX-64bit-10.6.app/Contents/Resources/sage/をみてみればいい。まるで科学計算のパッケージを集めるのが趣味の人物の/usrディレクトリかと思うほど。ほんとに何でも入っている（そういえばgslまでしっかりはいってるのにFFTWは入ってない。なんでだろ）。
ところで、Windows版は面白いことにVirtualBoxかVMWareの仮想環境上で走らせるようになっている（Windows版のSageをダウンロードするときに同時にダウンロードするようになっている）。普通のアプリではもっともユーザの多いWindowsにまずポートされるのが普通だけど、Sageに含まれている多くのライブラリがLinux上で開発されていてWindowsへのポートの完成度に大きな開きがあるのが一番の問題らしいが、WindowsのネイティブにしたとたんdllがいっぱいインストールされてぐちゃぐちゃになるのでWindowsユーザにはこの形態が安全であるとは言える。
じゃあ、Sageそのものは何をやってるんだ、と思いがちだけど、実はこれはすごいことで、これだけ広範囲にわたるライブラリはそれぞれ好き勝手なデータ構造を定義していてそれを統一的に扱うことはできない。従ってそれぞれのデータ構造に変換する必要がある。これをPythonのブリッジを作って（既にある場合はそのまま流用して）すべてをPythonのデータ構造として扱っている。
また、特にクロスプラットフォームな開発では非常に重くなるUIは、既存のWebブラウザを使うことでプラットフォーム依存のコードを完全に排除している（Sage本体はレイアウトを作るhttpをブラウザに渡したあと、javascriptでtableを更新するだけみたい）。このためちょうどMathematicaと同じようにKernelとFront endが分離して、Sage本体はネットワーク上のサーバで実行するということができる。
非常に頭のいい方法である。
実際にSageを使いこなすというのは並大抵のことではないが、もしPythonのシンタクスに慣れていればSageのほかに何もいらない、ということにもなる。
6.1 僕にとってのSageの問題点
一般的なSageの問題点としては、あまりに巨大でいろいろな分野にまたがる計算をすると（あまりそういう人はいないとは思うけど）メモリ消費が膨大なものになるということ。またUIもかゆいところに手が届く、というところはなく、一見スマートだけど、使っているとどうも端々で無骨な感じがしてくる。また、分野がオーバーラップするライブラリも多く含まれていて、Sageがどのように使い分けているかはよくわからない（使い込めば癖がわかるかもしれないけど）というところも精神衛生上よくない。さらに僕自身はそういう問題以外に、Sageを使っているとフラストレーションがたまってくる。いくつかの原因があるけど、まず
- Pythonに慣れてない
初めて見たときはインデントでブロックを表すやりかたが面白いと思った。会社に入ったばかりの頃HPのpascalを使いだしてbegin-endでブロックを表しているにもかかわらず、エディタ（USCD Pascalのエディタ）がインデントを強制するようになっていた。それなら見た目がうるさいbegin-endをやめてインデントで表せばいいのに、と思っていたのでPythonのやりかたを知ったときは「ほら、言った通りでしょ」という感じだった。
ところがこれがくせもので、結局見慣れないせいでブロックの範囲がかえってわかりにくかったりする（インデントでは空文が表現できないのに、空文を排除していないとかいうところもちょっとひっかかったりする）。要するに慣れが必要だということ。僕は慣れるほどPythonを使い倒していない。
Pythonのシンタクス以外にも、Sageを使っていてフラストレーションがたまる原因としてなににもまして
- 僕はSageを使いこなすほど頭は良くない
6.2 僕の目標は?
ということで僕はSageとは違う方向に行きたい。つまり、- （開発の）結果ではなく過程を楽しむ
- 労力をいとわず地道な方法を選ぶ
- なんでもできる（多機能性）を追わない
- 実装とアプリとしての使い勝手の両方がシンプルになるようなアイデアのみ採用する
Sageのおかげで僕の進む方向がはっきりしたような気がする。
2011-11-07 22:40
nice!(0)
コメント(4)
トラックバック(0)
頭よくない的なことを言われちゃうと、数学知らない自分なんかは一体？…てな気もしますが。
難しい話題をすれば絡まれる。卑下をされると周りが困る。意地を通せばどうなることやら。とかく人の世は住みにくい、ですね。
最近、Macのプログラミングの勉強始めたので、なんちゃってMathematicaの開発過程に期待してます。（Objective-Cって、取っ付き辛いですね。今時の言語は+で文字列を連結できるもんだと思ってました）
by きん (2011-11-07 23:25)
コメントありがとうございます。
失礼しました。でも、これは卑下でもなければ過剰な謙遜でもなく、Sageに対する僕の正直な感想です。http://www.sagemath.org/development-map.htmlをみると、なんだかすごそうな人がいっぱい並んでます。
ところでご指摘の通り、文字列連結だけでなくObjective-Cはキーストロークを減らすことや、字面を整理することにあまり熱心ではないようです。僕も演算子のオーバーライドぐらいあってもいいと思っていました。Objective-Cのソースの字面を較べると、例えばC++なんかは明らかに遠目に「白」く見えます。
Objective-Cはソースを英語として読み下せるように書いてくれ、という思想があるようですが、レガシーなCの記述を内包しているのではっきり言えば中途半端です。あとは要するに慣れなんでしょう。僕も最近はあまり苦にならなくなりました。
by decafish (2011-11-08 20:57)
リンク見ました。大学教授の名前がいっぱいで驚きました。で、納得しました。（笑）
Objective-Cは慣れるしか無さそうですね。英語で読み下せるように配慮してくれても全然嬉しくないですが、演算子のオーバーロードにいちいち気を使う必要ないから、分りやすいと言えばそうなのかもしれず。
by きん (2011-11-09 00:25)
Sage以外のオープンソースプロジェクトであんなふうなやりかたでContributorを紹介しているところを僕は知りません。ちょっと、なんだかなあ、と思ってしまいます。
僕はC++の仕様は複雑すぎて頭に入りません。たまにしか書かないせいもありますが、サブクラス間のアクセス制御のコードなんかはイッパツでコンパイルできたためしがありません。それに較べるとObjective-Cは仕様が小さく、なんだったっけ？と悩む場面がC++に較べて圧倒的に少ないです。
Objective-Cは、僕のような脳内スタックの浅い人間に向いていると思います。
by decafish (2011-11-09 21:38)