なんちゃってMathematicaを作る

さてさて、また、新しいことを始める。

タイトルは「なんちゃってMathematica」（「なんちゃって」なんて古いか）だけど、Mathematicaのクローンを作りたいわけではない。タイトルの理由はいくつかある。あとで説明する。

1  はじめに

1.1  動機

もう7、8年前の話だけど、gslが1.0台にあがったとき、そのフロントエンドを作ろうと思った。gslは単なるライブラリなので、自分で目的にあったコードを書いてgslをリンクして動かす、というのが普通の使い方で僕も多項式フィッティングやチェビシェフ近似など部分部分を使っていたが、gslが全体として充実した広い数値計算の範囲をカバーしているということに気がついた。そこでなんとなく汎用の計算環境として使えるのではないか、と思っていた。

たとえばMATLABは、もともとはLINPACK（LAPACKの前身）のフロントエンドとして作られていた。MATLABはいろいろなところで使われている汎用のソフトウェアで、非常に高速な数値計算能力とそれをグラフにきれいに表示することができる。ただし、MATLABはプロプライエタリなソフトウェアで非常に高価（数十万円）である。

ようするにLINPACKに対するMATLABのようなものをgslに対して作れないか、と思ったのである。もちろんLINPACK（あるいは現在のLAPACK）に較べてgslは実行効率は低いし、バグは多い。でも逆にだからこそフロントエンドを作る意味があるのではないか、と考えた。少なくともLAPACKをライブラリとして使っている人の数よりMATLABのユーザのほうがずっと多いだろう、LAPACKがフリーでMATLABは何十万もするにもかかわらず。

1.2  MATLABクローン

ちなみにやっぱりMATLABは高いので、MATLABクローンがいくつか作られている。有名なのはOctaveでMATLABのコードをそのまま読み込んで計算することができる。ただし、グラフ表示はgnuplotにデータを渡して実行するようになっていて、ときどきちぐはぐな動作をすることがある。もう少し新しいクローンとしてscilabというのがあって、こっちはグラフプロット環境も自前で持っていて美しい表示ができるようになっている。

Octaveは計算エンジンは自前のものを持っていて、MATLABのように枯れたLAPACKをベースにしたりということはしていないらしい（さすがにFFTWはライブラリをまるごと持っている）が、ScilabのほうはLAPACKをはじめとするNetlib（しばらく行かなかったら膨大な量になっている。MATLABからのフィードバックもあるみたい。しかしこれでは何がなにかわからない）のライブラリやFFTWなど、たくさん含んでいるらしい。MATLABの広範囲にわたる数値計算機能を独自実装していたのではするのはかなりの作業量になってしまうので限界があるのは目に見えている。ちなみに、MATLABのほうがバージョンアップが頻繁で、どんどん新しい機能を追加していくせいで、クローンのMATLAB互換性が損なわれるという事態になっている。

1.3  MATLABが気に入らない

実は、僕はMATLABがあまり好きではない。なぜかというとシンタクス（ユーザにとっての入力用の文法）があまりすっきりしていなくて、全然覚えられないからである。C風のキーワードをたくさん持っているが、使い方がCとは微妙に違ったりしている。

例えばif文、for文、while文、switch文などはendキーワードで終わらせる必要がある。こういうところはCというよりはshell scriptを書いているような気がしてくる（ところで、ここの「シェル (sh, csh...)」のところって、僕のことだ...）。こういうスタイルはインタプリタにありがちだけど、インタプリタだとこうしないといけない、という技術的な理由はない（構文解析がこの部分に関してだけ簡単にはなるけど）。

またすべての機能が関数呼び出しの格好で入力することになっていて、引数の多い関数は入力も煩わしくなる。

そういったMATLABとの相性の問題と、僕の場合簡単な計算はMathematicaでやってしまうほうが手っ取り早いし、Mathematicaには重い数値計算が必要な場合は、CやObjective-Cでハードコードして計算結果を得ることが多かったので、MATLAB型のインタプリタの出番はあまりなかった、というのが正直なところ。

1.4  ということで

ということで、こういうのを作ることはできないか、と思った。それは

• 計算エンジンはgslを使う
• シンタクスは整理されたものにする
• 従ってMATLABとの互換性は考慮しない
• すべてをGPL準拠にする

こうすればgslの開発が継続される限り、なにもせずにgslの最新の成果を取り込むことができて、手間が省ける。問題は

• グラフプロット機能をどうするか
• どのようなシンタクスを採用するか

となる。

そして、どうするかを先日決めた。つまり、

• グラフプロット機能は自分で実装する
• シンタクスはMathematicaをまねたものにする

1.5  グラフプロット機能

フリーなグラフプロット機能というと、なかなか得られない。やはりgnuplotか、Plplotなどがあるが、最終的にpdfにしたときに美しくない（PlplotではPostScriptのファイルも作れるがどうもX-Windowくさい絵になる）。そうなるとグラフプロットは独自実装しないといけない、ということになる。

そうなると、以前やりかけていてほったらかしにしてあったプロットフレームワークをちゃんと最後まで作ればいい、ということになる。どうせ今までやってたんだから、とはいうものの実はコードはまだ1行も書いていないので実質的にこれから、ということになる。

1.6  シンタクス

シンタクスは、ユーザの使い勝手はもちろん、設計上は構文解析や字句解析の負担を大きく左右するので重要である。字句構文解析を簡単にしたいために、あまりに制限の多いシンタクスになってしまう、ということはできればさけたい。

それにシンタクスの設計はなかなか難しい。一貫性があって、曖昧な表現の入る余地がなく、可読性が高く、入力もしやすい、というのが望ましい。しかし取っ付きやすさや使いやすさまで考えると、なるべく既存の言語にあわせる、というのがいいということになってしまう。C++やObjective-CがCのシンタクスをそのまま使っているのは当然としても、Javaが似ているのは見かけの敷居の低さ以外には考えられないし、pascal派ともいうべき（ALGOL系というべきか）Simula、Modula-2、BLISS、Adaなんかの大集団がある（死語も多いけど）。これらは単にキーワードが同じと言うだけではなく、構文解析手法もそれぞれ似ている。

しかし、機能を増やすたびに新しいキーワードを追加していくとそのうちユーザの方が覚えられなくて、昔の高機能BASICインタプリタのようになってしまう。何か違うことをしようとするたびに、分厚いマニュアルをひっくり返さないといけない。それは避けたい。

となると、僕にとっていちばん身近なインタプリタ言語というとMathematicaだけど、MathematicaもプロプライエタリなソフトでMATLAB以上に高価なので、本来なら「そんなもんしらんわ」と言いたいところ（いや、めちゃめちゃ使ってるし）だけど、MATLABと違って入力シンタクスに対する問題意識があって、いろいろ工夫されている（Wolframはこんなところでもえらかった）。これを見習うことは意味があると考えた。

コメント 9

数学とか門外漢なんですけど、なんだかすごい話ですね。
私は一応プログラマだったんですけど、こうしてスキルを積み上げて自分がやりたい新しいことに挑戦されるのを見ていると、なんだかこっちまでやる気が出てきます。
私も何か挑戦しようっと。
by きん (2011-10-31 01:13) 

楽しみです。Mathematicaのように、「シンプルな原則」で「世界」を作るというのは、とても魅力的そうです。特に「（それを作る）作り手」にとっては、限りなく魅力的に思えます。
by jun hirabayashi (2011-10-31 19:32) 

コメントありがとうございます。
ね、面白そうでしょ？
なんて言ってるけど「作ると宣言する」というのと「実際に作る」のとは天と地ほどの差があるのはご存知の通りです。
どこまでできるかは、これからの進捗を見ていて下さい。
そのうち、シレっと無かったことにしてるかもしれません。
そのときは「やっぱりね」とか言わずに「忘れてない？」とか突っ込んで下さい。
よろしくお願いします。
by decafish (2011-10-31 20:21) 

こんにちは．

御構想のものは，メモリ使用量は，Mathematica よりも小さいでしょうか？　（私も Mathematica をよく使いますが，昨日，それまで動いていた500×500 の規模の計算を，1000×1000 の規模に変更し走らせてみましたら，8 GB メモリを使い切ってしまいました．）

ところで，Mathematica よりも R を勧める人もいるようです（経済学教育用に）．ご参考まで．
「Mathematicaはもういらない　大坂洋」
http://www3.u-toyama.ac.jp/tulip/ws/ws18osaka01.pdf



by zyz (2011-11-04 19:17) 

コメントありがとうございます。
まだ単なる思い付きでしかないので、メモリの使用量などはわかりません。とはいうものの、Mathematica以上にメモリを消費するのはかえって難しいくらいです。Mathematicaのメモリ喰いはひどい（しかも遅い）ので、僕もある程度大きな数値計算が必要な時はCなどでハードーコードしています。
ご指摘の大坂さんの発言は存じていました。「R」はもともと統計計算用のソフトウェアで、そちら方面が充実していますが、代数計算の機能はないのでMathematicaの代わりにはなりません。本来、代数計算をしない人がMathematicaを使う必要はまったくないと思います。その意味で大坂さんの主張は正当です。

そういえば「R」も「S」のオープンソースクローンですよね。
by decafish (2011-11-06 20:46) 

こんな「新言語」が出ていました。ご存じかもしれませんが、参考まで。
http://d.hatena.ne.jp/amarui/20120221/1329823079
by jun hirabayashi (2012-02-22 20:09) 

コメントありがとうございます。
うわあ、これは面白いです。Matlabでも不満だと思う人がいるんだ。このひとの翻訳もかわいいです。ふんふんふんふん、と頷いてしまいました。Windowsをサポートしていない、というのもくす、っと笑ってしまいました。

そうかあ、JITコンパイラかあ。ユーザが明示的にループを記述する言語では高速化が期待できそうですよね。gccを丸ごと使わずにLLVMを独自実装したのかなあ。すごいなあ。

トップページのベンチマークはMatlabが得意な線形計算が含まれていなくてちょっと「？」な感じもしますが、C++より百倍近く速いpi_sumってどんなコードなんでしょ。

いいなあ、僕もこのくらい元気にやりたいなあ。僕ももうちょっと若ければ．．．．
by decafish (2012-02-23 21:08) 

> C++より百倍近く速いpi_su

　あの表は「C++は実行時間（ms）で、その他はC++を１とした場合の相対時間」ですね。
　Julia使ってみたのですが「ユーザが明示的にループを記述する」コードはめんどくさいなぁ…と感じ始めました。やはり、Mathematicaっぽいのが良いかも…。
by jun hirabayashi (2012-02-26 06:08) 

そうですね、僕の早トチリでした。ありがとうございます（表のキャプションさえ読んでないことがモロバレになりました）。
MatlabのヘビーユーザにとってはMathematicaのMapやThreadやFoldは気持ちが悪い、というのはあるような気がします。でもMatlabでも行列演算はループを書かなくてもいいんですよね。やっぱり慣れなんでしょうか。
ところで、Juliaをコンパイルしようとしてるのですが、gitがクラッシュしてしまうんです。うう、なんでだろ。何もしてないのに。
しかし、Juliaの「なぜ僕らはJuliaを作ったか（Why we created Julia）」みたいなのを僕も書きたいです。「欲しいけど、ない。では、作ろう」とさらっと言えるのはカッコいいなあ。動機が「ボケ防止」とはえらい違い．．．．
by decafish (2012-02-27 21:43)