電脳Rubyプロジェクト概要堀之内武（京大生存圏研究所）, 西澤誠也, 高橋憲義, 水田亮, 豊田英司, 塚原大輔, 竹本和彰, 小高正嗣, 林祥介, 石渡正樹, 塩谷雅人, 乙部直人、中野満寿男, 中島健介, 神代剛, 谷口弘智, 電脳Rubyプロジェクト目的 • Rubyを地球・惑星流体データの解析、可視化、シミュレーション、データベースに用いるための基礎的なライブラリー群を開発する。なぜ Ruby？ • 型なし、スクリプト言語（インタープリター） ⇒ 素早くプログラムが開発できる • 洗練され使いやすいオブジェクト指向言語 ⇒ 開発・保守効率がよく、汎用なソフトを作り易い ⇒ コミュニティーでツールの共有 • 対話的に利用可能 ⇒ 試行錯誤に良い • 拡張性が高い ⇒ CやFortranのライブラリーの有効利用 • 増え続けるライブラリー（ネットワーク関連 / GUI / データベース等々） ⇒ 高度なサービスを実現しやすい。 • 文字処理が容易（データ解析中に文字処理が必要になることは多い） • ゴミ集め、例外処理等の近代的支援機能あり既存のツール・言語があるじゃん？ • IDL, Matlab – 手続き型 ⇒ 汎用なプログラムを作りにくい – IDL: 拡張性・発展性に乏しい。Matlab：いろんなツールボックスがあるけど揃えるのは高価。 • GrADS – 気象分野ではよく使われているが出来ることが限られすぎ • C,C++,Java,Fortran – データを前に試行錯誤する現場において直接使うのは非効率。むしろインフラ整備向き。 Rubyの利用：実行速度の問題 • 流体の場合、計算量を増やすのは主にデータサイズ（グリッド数） ⇒ – Cのべた並びポインターを構造体にくるんだ多次元数値配列クラスNArrayを利用 – C等で書かれた既存数値計算ライブラリーをラッピング地球流体電脳倶楽部電脳Rubyプロジェクト • 地球・惑星流体の研究・教育にRubyを活用するためのプロジェクト • 基本的にボランティアベース • 現在は、格子点データの解析・可視化関連の開発と情報交換が中心電脳Ruby ホームページ（日本語版） http://ruby.gfddennou.org 地球流体電脳倶楽部トップは http://www.gfddennou.org 電脳Ruby ホームページ（英語版） http://ruby.gfddennou.org 主な電脳Ruby製品の一覧 (2004年5月現在) 多次元配列 NArray 基礎その他数値配列数値計算・統計ﾗｲﾌﾞﾗﾘ Misc ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ補助 NArrayMiss 欠損値付 Units 単位 Multibitnums 多ビット整数（１Ｄ）ファイルIO RubyNetCDF NetCDFラッパ RubySSL2 SSL2ラッパー FFTW3 RubyFFTW3 ラッパー GrADS_Gridded GPV GrADS形式気象庁データ中間データハンドリング基礎応用グラフィックスグラフィックス RubyDCL DCLラッパー格子点上の多次元物理量を GPhys 包括的に扱うライブラリ GUI・グラフィックス遠隔データアクセス GPhysデータの GGraph GPhys可視化 gave 解析・可視化 gphys_remote サーバー・クライアント（GPhys付属）枠の色：（ほぼ）安定結構開発が進行地の色： Pure Ruby Cによる拡張ﾗｲﾌﾞﾗﾘ初期段階斜線：ﾌﾟﾛｼﾞｪｸﾄ外「中間層」：格子点データ取り扱い基礎ライブラリー GPhys • 名前は Gridded Physical quantity より • 格子点状に離散化された多次元の物理量を抽象化したクラス • 配列データ、格子etc関する付加情報を持つ。単位有。 • データの実態は様々あり得る（統一的に扱われる）： – メモリ上の配列プラス付加情報 – ファイル中に存在（現在はNetCDFとGrADSの2形式） – 他のGPhysのサブセット／複数GPhysの合成 • 数学・統計演算などサポート（但しまだ限られている） • メモリー上に乗り切らない巨大データも扱えるよう配慮応用ライブラリー • GPhysを利用する形で構築 – グラフィカルユーザーインターフェースgave （by 西澤） – 分散オブジェクトによる格子点データの遠隔サービス gphys-remote（プロトタイプ版）分散オブジェクトライブラリーdRuby利用 – GPhys可視化ライブラリーGGraph • GPhysを利用する利点 – 応用プログラムをデータの物理的な構造による制約から解放： • GPhysがサポートするファイル形式が増えれば、応用ライブラリーが扱えるファイル形式が自動的に増える。 • ファイル中のデータと、それを読み込んで加工したデータが全く同列に扱える。 gaveのスクリーンショットパッケージ化 • Linux用：Debianパッケージ、RPM • Windows用：VC++版用（整備中）、Cygwin パッケージ • UNIX系汎用一括インストーラー（ダウンロード込み）今後期待される発展 • インフラの一層の充実！ – 数学・統計処理や気象学等個別分野用ライブラリーなど（汎用なライブラリーが作りやすい ⇒ コミュニティーのソフトウェア資産形成） – サポートするファイル形式の増加、などなど • gave等のGUI, グラフィックライブラリーの充実 • 分散オブジェクトの活用 – データベースとの連携による、遠隔データの解析・可視化の充実 – データ公開サーバー構築 • Webサービス • 数値シミュレーションへの応用 – シミュレーションコードが短く、見通し良く書ける。但し遅い。 – 別言語のコード生成（中野らの発表） fin なぜオブジェクト指向？ • データの抽象化が必要 – 似たような、しかし異なるデータが沢山（ファイル形式、次元性、ジオメトリ、単位…）。 – 抽象化しないと、微妙に異なるプログラムが沢山必要。（プログラムの再利用性が悪い。∴コミュニティーでツールの共有が難しい。） [抽象化：物理構造ベース⇒論理ベース] • コンポーネント間の依存性を減らす必要 – 組み合わせて使うソフトが、それぞれ互いの変更に出来るだけ影響されないようにしないと維持が大変。