R : Past and Future History の訳

著者 Ross Ihaka は Rober Gentleman と共同で R の初期バージョンを開発し、R の開発に一貫して従事している。R というネーミングは S の一歩手前という意味、というのが定説(?)だが、両者のイニシャルから取られたという風説、さらには R を R^2 (R squared)と呼ぶべきという冗談半分の提案もある。この論文は R のバージョン 1.0 がでる見通しがたった時点でかかれたもので、R の出生の秘密を知ることのできる格好の資料である。

R のコンパイラーの試みが既にあるのですね。そう遠くない将来(バージョン 2.0 ?)、「R は所詮インタプリタ言語だから」という言い訳をしないで済むようになる?

R : 過去と未来の歴史

Ross Ihaka, Statistics Department, The University of Auckland, Auckland, New Zealand

Interface '98 への論文の原稿

要旨

R は、統計環境を如何にして構築するかについてのアイデアを試すことのできる、小さなテスト用の試験台を Lisp の移植手法を用いて構築しようという試みとして始まった。ごく初期に、S 風の構文を使おうという決定がなされた。一旦この決定がされると、ますます S に似せようという動きが抗い難くなってきた。

R はいまやその起源から脱皮し、その現在の発展は、インタネットを用いたアイデアの交換と結果の配布に基づく、共同作業による。いまや、実験的試みを実行可能なフリーソフトの一部に如何にして仕上げるか、に焦点がある。

この論文は、R の過去と現在を概観し、未来の発展が行きつき得るところを手短に省察する。

起源

かなり前に、私は Hal Abelson と Gerald Sussman による The Structure and Interpretation of Computer Programs という素晴らしい本を見つけた。この本の目的は、工学系の学生に Scheme プログラミング言語を用いた計算法を紹介することである。 それは、興味深く実際的な幅広い例を取り上げ、さらに Scheme のような言語を移植する方法までも示した、素晴らしいプログラミングの展望を示している。

ほぼ同じ時期に、私は Rick Becker と John Chambers の新しい S 言語の最初のリリースを使う機会を得た。S と Scheme の間の類似点と相違点に気づいたことを覚えている。特に、ある時 Alan Zaslavsky に、どうすれば構文的スコープ規則がそれに固有の変数を持つことができるのか、説明したいと思ったことを覚えている。 手元に使える Scheme のコピーがなかったため、S を使って彼に説明を試みた。その試みは、S と Scheme のスコープ規則の違いから失敗に終った。そのせいで、私は S に有用な機能を付け加え得る余地があると考えるようになった。

かなり後になり、Robert Gentleman と私はオークランド大学で同僚になった。我々は共に、統計計算に関心があり、我々の Macintosh の使用法を教える研究室用のより良いソフトウェア環境の必要性を感じていた。使えそうな商用環境は無く、我々自身で開発したらどうなるのか試してみるための実験を開始した。

Scheme 風の小さなインタプリタから始めるのが一番自然に思えた。なぜなら、その当時入手可能であった多くのフリーの Sccheme インタプリタを採用せずに、我々自身でインタプリタを書こうと決めたからには、おそらく本質的な内部機構の変更をする必要がでてくることは明らかであったから。これは決して最初思えるほどには、気遅れするような作業ではない。プロセスは Abelson-Sussman や Kamin の本に十分に説明されている。いくつかの Scheme インタプリタのソースコードを眺めることが、具体的な実装の詳細を理解するのに役立った。

我々の最初のインタプリタは1000行のCコードからなり、R の現在のバージョンに見られるかなりの関数機能を備えていた。インタプリタを役にたつようにするため、統計作業を支援するデータ構造を加え、ユーザインタフェイスを選ぶ必要があった。我々はコマンド実行型のインタフェイスが欲しかったし、共に S を熟知していたので、S 風の構文をつかうことは自然に思えた。

この決定は、他の何にもまして、R の発展がたどった方向を導くことになった。先に述べたように、Scheme と S の間には非常に強い類似性があり、我々のインタプリタに S 風の構文を採用したことは、S への著しい相似性を感じさせる特徴を生み出した。この最初の一歩を踏み出したあと、我々はますます S の特徴を採り入れることになった。

R と S の類似性にもか代わらず、いくつかのキーとなる違いがある。二つの基本的な違いは、R が Scheme の伝統を受け継いでいることに由来する。

  • メモリ管理: Rでは、起動時に一定量のメモリを確保し、進展につれて実行されるガベージ回収機構でそれを管理する。これはヒープの増加が極めて少ないことを意味し、結果として S に比べるとページングの問題がより少ない、
  • スコープ規則:S では関数中の変数は、局所的であるか大局的であるか、のいずれかである。R では、関数は、それが定義された時点で有効であった変数にアクセスすることができるようにした。このアイデアは ALgol 60 にさかのぼり、Scheme やその他の 構文的スコープ規則を持つ言語で見受けられる。次の図で定義された関数を考えよう。この make.counter という関数は、それ自身関数である値を返す。この "内部関数" は total という変数の値を増加させ、それからその変数の値を返す。S では操作されている変数は大局的である。R では、それはこの関数が定義されたときに有効であったものである。つまり、それは make.counter に対する変数である。実際の効果は、この内部関数のみが見ることができ、操作することができる変数をつくり出すことである。
R のスコープ規則が S のそれと如何にことなるかを示す簡単な関数の例
       > total <- 10
       > make.counter <-
       +   function(total = 0)
       +     function() {
       +       total <<- total + 1
       +      total
       +     }
       > counter <- make.counter()
       > counter()
       [1] 1
       > counter()
       [1] 2
       > counter()
       [1] 3

一般的にいって、R で用いられているスコープ規則は、非常にすっきりしたプログラムスタイルを可能にするため、好意的に受け入れられている。我々は、それがインタプリタの実装を複雑にするものの、継続し続けている。

上に注意した二つの差異は、非常に基本的な性格を持つ。更に、我々は R に幾つかの他の特徴を実験的に取り入れている。実験の多くはグラフィックス(S のそれに酷似している)に関するものである。こうした実験的試みの幾つかを以下に簡単に解説する。

  • カラーモデル:R はデバイスに依存しない24ビットのカラーモデルを使う。カラーは幾つかの方法で指定できる。
    • 1. カラーを構成する赤、緑、青成分の水準を指定する。例えば、文字列 "#FFFF00" は赤と緑を最大にし、青成分を皆無にし、黄色を生み出す。
    • 2. カラー名を与える。R は X ウィンドウシステムのカラー名を使い、約 650 種類の標準カラー名を提供する。普通の "red", "green", "blue" から、よりエキゾティックな "light goldenrod" や "medium orchid 4" に渡る。
    • 3. ユーザーが設定可能なカラー表へのインデックスを使う。これは S のグラフィックスシステムとの一貫性を与える。
  • 線種のテクスチャの記述:線のテクスチャもまた柔軟に記述できる。記述方法は:
    • 1. テクスチャ名 (例えば "dotted")
    • 2. 線を構成するペンの上下線分に対する長さを含む文字列。例えば、指定 "52" は "ペンを下げる" 動作を5点 (もしくは 5 ピクセル) 分し、ついで "ペンをあげる" 動作を2点分行なう動作を線の長さ分繰り返す。
    • 3. 線種の一定の範囲へのインデックス。再び S との一貫性のために用意されている。

次の図は白色雑音時系列のペリオドグラムのプロットで、数式表現の利用法を示す。

  (図省略)
  • 数式表現:Paul Murrell と私はプロット中に数式表現の注釈をつくり出す簡単な方法を検討してきた。数式表現は、文字列の代わりに、未評価の R 表現式を指定することにより、作成される。 例えば、expression(x^2+1) はプロット中に注釈として数式表現 x^2+1 を入れるために使うことができる。この注釈システムはかなり簡単なものであり、TEX 等のシステムの機能を完全に持つようにはデザインされていない。それであっても、極めて良好な結果を得ることができる。図 * は R で作られた時系列ペリオドグラムの簡単な例を示している。このプロットはラベルを記述するために表現式を用いた、単独の R の命令でつくり出された。
  • 柔軟なレイアウト:Paul Murrell は彼の学位論文の一部として、プロットのレイアウトを指定するためのスキームを探索してきた。このスキームはグラフデバイスの領域を幾つかの矩形領域に分割する仕方を指定する単純な方法を提供する。こうした領域は様々な方法で条件を指定できる。Paul の最初の仕事は Lisp で行なわれたが、彼は R の有用なサブセットを実装した。これらのグラフィックスに関する実験はオークランドで行なわれたが、他の人達も、またそうした実験の基礎として使用できる環境を R に加えてきた。
  • コンパイル:Luke Tierny は R をバイトコードコンパイルすることによりどのような実行速度の向上が得られるかを見るための実験を行なってきた。彼の実験は、幾つかのインタプリタコードでは20倍程度の速度向上が可能であることを示している。現在のところ、R の内部データ構造はこの作業を追求するに十分なほどは恐らく安定ではない。
  • WWW インタフェイス:Jeff Banfield は RWeb を開発してきた。これは WWW に基づく R へのインタフェイスである。
  • Tcl/Tk インタフェイス:ごく最近になり、Balasubramanian Narasimhan は Tcl/Tk が如何にして R に完全なグラフィカルユーザーインタフェイスを付け加えるのに使用できるかを検討し始めた。

フリーソフトウェア プロジェクト 手短な歴史

Robert Gentleman と私による初期の R の作業は潜在的に有用と思われるソフトウェアの断片を生み出したが、我々はそれを我々の講義で使用するための準備を始めた。R のバイナリのコピーを Statlib に置くことができるまでに進展したことで大いに勇気づけられ、1993 年の 8 月に s-news に短い案内を出した。

何人かが我々のバイナリーを取り上げ、フィードバックを提供してくれた。彼らの内、最も熱心だったのが ETH Zurich の martin Maechler であり、R のソースをフリーソフトウェアとして公開することを勧めてくれた。

我々は最初これに懐疑的であったが、Martin の議論は説得的であり、ソースコードをフリーソフトウェアファウンデーションの GNU の一般公開許諾契約書の条項のもとで、ftp で入手できるようにすることに同意した。これは 1995 年の 6 月もことであった。

この時点では、R ん開発は相対的に閉じた過程であった。Robert と私(すぐに Martin も加わって)は電子メイルでバグ報告を受け、時おり R の新バージョンを公開した。直ちに、R について互いに議論するユーザーの場が無いことに気づき、小さなメイリングリストを設けた。

(主に口コミで) R への関心が育つにつれ、人手でメイリングリストを維持することは効率的でないことが明らかになった。もっと悪いことに、オークランドでは電子メイルに料金を払う必要があり、経費が無視できないようになってきた。ついに Martin がボランティアで ETH Zurich の設備を使って、R と R の開発に関する議論を行なうためのメイリングリストを自動化してくれた。1996 年の 3 月には R の試験的使用者のメイリングリストが始まった。ほぼ一年後には、これは r-announce, r-help そして r-devel という三つのニュースグループに置き換えられた。

R が発展し人々がそれ用にアプリケーションを移植し始めるにつれ、もっと優れた配布機構が必要なことが明らかになってきた。幾つかの議論の後、我々は公式のアーカイブ機構が望ましいという結論に達した。TU Wien の Kurt Hornik がアーカイブを作る作業を請け負ってくれた。更に、オーストリアのマスターサイト以外に、Statlib を含む幾つかのミラーサイトがある。

メイリングリストの導入とともに、R の発展は加速された。これは、一つには我々が益々多くのレポートと提案を受けとるようになったこと、そしてパッチや貢献コードを受けとるようになったことによる。貢献は、字句の間違いの訂正から、機能や実行速度の本質的な増加を与える変更に及んだ。

貢献のレベルは、Robert, Martin そして私が、変更に対する依頼にいつも十分な速度で対応できないほどであった。結果として、1997 年の半ばに、我々は、ソースコードの CVS アーカイブを変更できる資格をもった大勢の "コアグループ" を設けた。このグループは現在次のメンからなる

   Doug Bates, Peter Dalgaard,
   Robert Gentleman, Kurt Hornik,
   Ross Ihaka, Friedrich Leisch,
   Thomas Lumley, Martin Maechler,
   Paul Murrell, Heiner Schwarte,
   そして Luke Tierney. 

R に関するすべての作業は性格から厳格にボランティアであり、組織は非常に緩やかなものである。メンバーは暇があり、そして作業すべきことがある時貢献する。

貢献者

Robert と私が R の作業を始めた時、我々は我々の入門的なデータ解析コースで教えられる何かをつくり出せることを期待していた。もし我々だけのために作業を続けていたら、正しくこれだけが我々が達成できたことであったろう。

R をフリーソフトウェアにするという決定は、このプロジェクトに多大な努力を喜んで払う、非常に才能ある人々の大きなプールに接触することを可能にしたため、我々はかなり高い到達点を設定することができるようになった。実際、R について作業する最大の利点の一つは、そうした偉大な人々の集団と一緒に作業する機会であった。

上に挙げたコアグループ以外に、次の R への重要な貢献をしてくれた人々に感謝したい。

   Valerio Aimale, Ben Bolker,
   John Chambers, Simon Davies,
   Paul Gilbert, Arne Kovac,
   Philippe Lambert, Alan Lee,
   Jim Lindsey, Patrick Lindsey,
   Mike Meyer, Martyn Plummer,
   Anthony Rossini, Bill Venables,
   Gregory Warnes, そして
   mward@wolf.hip.berkeley.edu 

(完璧でないことを詫びたい。我々の保存している記録、はそうあるべきほどには完全でなかった)。

さらに、他の大勢の個人が貢献をしてくれた。

現状

R は依然として、活発な発展を続けており、広く使われる態勢ができたと考えられるには、さらに幾つかの作業がいる。特に、大規模なデータセットを管理するサポートをするための幾つかの変更が必要であろう。より重要なことは、S についてかかれたものの多くがそのまま R に使えるものの、入門的なドキュメントがほぼ完全にないことである。

これにも関わらず、R は通常の使用(特に Unix では)に十分なほど安定していると考えられる点に到達し始めたように見える。来年には、フリーソフトウェアファウンデーションの一連の GNU ソフトウェアのひとつとして完全なバージョン 1.0 の R のパッケージを公開できることを我々は期待している。

将来の R

R プロジェクトの現在の目標は、バージョン 3 の S に "近い" あるもののフリーな実装をつくり出すことであり、結果のソフトウェアの持続的なサポートと維持である。R コアのあるメンバーはバージョン 4 の S の将来の発展にも追従すべきだと提案している。今の時点では、これが行なわれるかどうか不明である。

R を大いに助ける発展は、統合されたグラフィカルなユーザーインタフェイスであろう。これについてはある初歩的な作業が始まっており、私はまもなく実現されるであろうと信じている。

私の R に対する個人的な将来の興味は主にユーザとしてのものである。それに費やした投資に対し、統計研究と教育に R を徹底的に使ってみたいと希望している。

関連した作業

R について作業してしたことから、統計ソフトウェアの構築に関連する幾つかの興味ある問題が私には見えてきた。私自身の結論は、効率性の問題、特に速度を追求することが重要だ世いうことである。

先の節で述べたように、Luke Tierney はバイトコードコンパイルを使うことにより、どの程度の速度の増加が期待できるか幾つかの実験を行なった。それによれば、ある種の計算機では 20 倍程度の速度の増加が可能かも知れない、という結論であった。

本来の機械コードへのコンパイルにより、100倍程度(大雑把にいって、最適化されていない C コードの速度)の向上が可能かも知れないという他の証拠もある。このレベルの性能があれば、外部言語へのインタフェイスも不必要かも知れず、すべての計算が単一の計算言語環境ですむこともあり得るかも知れない。

私はそうした環境が提供しうるものに興味をそそられている。この大きさの性能の向上は、おそらく、その使用法に対する質的な変化を生み出す可能性がある。

困難はそうしたコンパイル環境の創造は、コンパイルに関するエキスパートの手助けを必要とすることである。そうしたエキスパートで、統計家が扱うタイプの問題にも知識がある人材を見つけるのは本当に難しい。

謝辞

John Chambers と彼の AT&T の同僚の先駆的な仕事がなければ、R は存在しなかったであろうというのは、当たり前のことである。John は我々の多くの統計計算についての考え方を変え、R をそれにあたう限り似せようと工夫してきたことは、人々が S を使ったデータ解析を楽しんできた度合に対する証明でもある。

フリーソフトウェア運動 (もしくは、おそらく様々な運動)は R に対するアイデアと影響の今ひとつの主な源泉であり続けた。私は、開発作業を Free BSD OS が動き、Free Software Foundation の豊富な開発ツールを備えた、ワークステーションで行なっている。願わくば、R が、フリーソフトウェアのコミュニティへの、それが私や他の R 開発者に提供してくれたものへの、いくらかのお返しになることを期待する。

最後に、私の共犯者である Robert Gentleman に感謝したい。R に関する作業の間、我々は実のところ表裏一体であった。我々は今でも話をし合う仲であるだけでなく、金曜日の夜には一緒にビールを飲みに出かけるという事実が、何よりも雄弁にそれを物語たっている。


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Google
WWW を検索 OKADAJP.ORG を検索
Last-modified: 2015-03-01 (日) 01:15:59 (1723d)