Subject: meeting log 9/27,28 From: momoko@ees.hokudai.ac.jp To: dennou_davis@gfd-dennou.org Date: Tue, 28 Sep 1999 15:51:55 +0900 X-Mailer: Mew version 1.93 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mailing-List: contact dennou_davis-help@gfd-dennou.org; run by ezmlm 石渡です. 99/09/27, 28 のミーティングログです. # 表題 DCL インターフェースの検討 # # 1999/09/28 # ================================================================== ● 本日のお題 業務連絡(林他) 発表会 学会 DCL インターフェース(酒井) Ruby (堀之内) 構造 (石渡) ● 業務連絡 (1) 出張報告書 本日の出張報告書を, 各所属の然るべきところでハンコを もらってJST(の佐藤さんだっけ?)に送ってください. (2) 惑星科学関連合同学会でセッションを開催しましょう. ・惑星科学関連合同学会の概要 開催日は 6/25,26,27 あたり 場所は東京・代々木オリンピックセンター セッションの申し込みは〆切 10/15 ・セッション申し込みの概要 セッションの申し込みには以下のような事を書こうと思う. タイトル : 「計算機は地球惑星科学におけるデータの嵐を乗りきれるか」 英文タイトル : "Can we survive the data flood in earth/planetary sciences with the computer?" コンビーナー : 2,3 人. 一井先生には入って頂きましょう 短縮名 : データの嵐 内容紹介 : 問題は, 今日び, 何でもどこでもデータの嵐に人々が翻弄されつつある. 更に, 得られた結果なり成果なりを世の中にどうフィードバックするべきか 良く考えないといけない である. 本セッションの目的は, 上の問題点を踏まえて, 可視化の簡単な話から soi の方々をお招きしての講演まで幅広い話題に わたって議論することにあるだ. 想定している話題は, 数値モデル・観測より得られるデータをどう扱うか? ネットワークを通してデータをどう扱うか? ネットワーク透過なデータetc データ構造はどうあるべきか OS に依存しない構造にしたい データは何を知っているべきか? 大量データをホイホイ可視化するにはどうしたら良いだ? その他何でもである 合同学会において開催する意義(200字) : みんな困ってるでしょ. 単一の学会で収まる問題ではない. 人が多く集まれば, それだけ文珠の知恵が出るかもしらん. そのためには多くの人々に問題点が認識されることが肝要なんである. ・講演内容はどうするべ? この辺から 2,3 題出す. ruby に特化した話で 1 個. 誰かお客さん招けないかしら? 一井さん, 地球科学者でも知ってる派手い人いない? i-grid 東大情報基盤センター江崎さん 参照: http://www.startap.net/igdir School of Internet の人誰か 参照: http://www.wide.ad.jp/soi/ えびす崎さんを呼ぶことを検討した方が良いかもしれない(健介) (3) JST の発表会 時期 : 1 月下旬から 3 月上旬 いつが良いかを決めてmail を送らないといけない. 質問表に対する答え 希望する日時 : 3 月 6 日の週 希望する発表形態 : 口頭発表 ただし, 希望はしますがそうなるかどうかはわかりません. (4) NetCDF マニュアルの和訳が遅れそうです. 11 月にずれ込みそう. 数ページできたら送ってもらってfeedback をかける予定. ● DCL インターフェース(酒井) status を報告すると 大体予定通り f77 の奴に f90 の奴をかぶせて 1 対 1 対応させることはできた. ただちょっとすわりが悪い. 今それを直しているところ. 一番大きな不満の点は, 座標軸. 座標軸は grph2 にあってかなりの部分を占めている. uspack と他のパッケージとのつながりがあまりよろしくないのが 問題. その理由は, uspack と他の部分との思想が違う. uspack はおまかせで全てひっくるめてグラフをかく. uspack の中では, グラフをかくとかティックをかくなどの 各セグメントを切り離せない. 具体的には, uspack で一旦かいたグラフをちょっと直そうと したときに結構面倒臭いことになっちゃう. 座標軸をかく時は, USSTTL() USDAXS() とかしていくんだけど タイトルを直そうとすると, UX… を呼ばなきゃいけなくなったりして嫌だ. 基本的には, お任せルーチンがあって何も考えたくない場合はそれでグラフをかく. ちょっと直したい時はそれにちょちょっと手を加えていく という形にしたい. そのためには, 座標軸という概念は 軸, ティックマーク, ラベル, タイトル を全部まとめたものにしたい. ユーザーインターフェースとしては, 全て US レベルで用意する. unit はタイトルの中に入れることもできるようにしたい x 軸, y 軸も一つのルーチンで書くようにしたい. 引数で全部指定できるので x, y 軸それぞれのルーチンはいらない. 軸の指定は, T,B,L,R,H,V にしたらどうか? ということをやろうかと思って, ソースを見たら結構複雑だったので ちょっとpending. 後の問題は, XXPGET/SET 1 つにまとめることにしたんだけど パラメータ名は, SCALING.DXT とかする予定だったけど もっとわかりやすい別名をつけるようにもした. 長さのメドは 20 文字. 例えば, LINE_BUFFERIG_LENGTH. コマンドラインでの別名の指定は, 今後の課題. (もちろん昔通りに打てば, それは問題なく通るでしょう.) エラーメッセージ ユーザーが呼んだルーチン名で出して欲しい. これに対しては, 一番外側の「皮」のルーチン名だけ 出しゃ良いだろう. なので, 「皮」のルーチンが呼ばれたら, 「私呼ばれました」 をどこかに記憶しておけば良い(終了したら記憶を消すようにする) 古き良き時代の悪しき伝統は? Common 文はもう無いはず. 型が違うのを equivalence してたのは, 全部ばらすことに して, 型毎にルーチンを用意する(XXISET, XXRSET, XXCSET... etc). ただし, f90 では統合ルーチンを用意する. とりあえず, 古い人達(f77 ユーザー) の care は無視しよう. DCL6 は, f90 ということをもって旨としよう. ちなみに, 前も話が出たけどルンゲクッタの f90 用のインターフェース は作らないし, マニュアルにも載せない. ルンゲクッタに関しては, 酒井さんお勧めお作法は「自分で全部書きな さい」. だから, 本当に必要なのは, ルンゲクッタの template みたいな ものがのっているドキュメント(数値計算教科書)である. f90 でいらなくなったもの math1 の大部分(配列の値をset するなど). UDCNTR などで使っていた作業領域のことも, もう気にしなくて良いのだ. 塩谷さんに頼まなきゃいけないのは (1) 文字 : hardware font も使えるようにしたい. DCL の自前 font ではやはり, ユーザーさんは満足でけんだろう. 日本語でない 小さい文字つぶれちゃう. hardware font 結構きれいなのでこれを使わない手はないでしょう. ただ, 現時点では全部 hardware font にするというのは無理だろう. 例えば, 面に描いた文字を斜めの方向から見た時の文字を描く時は 自前で font をもたなあかんだろう. もちろん 2 系統持っているのは面倒臭いので, 将来的には美しい hardware font に統一することを考えていかないといけないでしょう. hardware font 部隊は, 高橋・乙部・塩谷かな? 文字列の横幅を返すルーチンと文字列の位置を指定するルーチン (真中とか右端とか)など奴らのすり合わせが必要になるでしょう. 「そこら辺を考えて, よろしく!」 あと文字に関しては, 現バージョンに対する不満 : overbar が描けない. 全部 hardware に頼ると文字の大きさを予測できなくなるのでは(豊田). 既に, 大きさを返すルーチンがあるので, それに手を入れれば良いのでは? (2) soft fill を無くそうよ. メンテを考えると soft fill を soft fill/hard fill の切替えがかなりやっかい. また soft fill の emuration のアルゴリズム自体が複雑に違いない. ● libf2c 問題(FIP 高橋さん) DCL で単純に f2c かけてだけで問題になったルーチンは 41 個. この41 個については, 必要なファイルを f2c ソースから取って来て DCL にリンクできるような libf2c のライブラリを作りました. 現状は, 各ユーザーのソースに f2c をかけて, 作成された DCL 用 f2c のライブラリをlink すれば, 動くようになってます. ● C 用の「皮」はどうするべ? 最低ラインは, 今できている FIP 謹製 f2c プロジェクトの製品でおしまい. だけど, もう 1 枚, f90バリの皮を作りたいよね? 作戦は, f90 の皮がだいたいできたら それを見ながら, C の皮のルーチン名を固定して ガシガシ作る それらの統括は「塩谷さんにお願い」だった. というものだった. しかし, f90 用の「皮」はかなり f90 に特化してしまったので 全く同じ物を C で作るというのは無理かもしれない. なので, 作戦もう一度仕切り直しした方が良いかも知れない. 作戦その 1 は, 今できている FIP 謹製 f2c プロジェクトの製品でおしまい. C で使う時は, f2c で直訳された ルーチン名をそのまま使う (underscore 付の名前) 作戦その2 は, 酒井さんが大体作った f90 の「皮」を見ながら, 同様にして C の「皮」をガシガシ作る(これ, 従来の作戦). どっちの作戦にすべきかは, 結局どう使うか/何を作りたいかによっていて, 例えば, ruby で使う時には, DCL を呼ぶ部分を全てライブラリ化 しちゃうんだったら, わざわざ立派な C の「皮」を作ることは ないでしょう. (要するに作戦 その1 ) というわけで, ここら辺も含めて考えてくれません? > 塩谷さん, 沼口さん ● データ構造の位置付け(復習) 数値計算等F90 -> F90インターフェース -> NetCDFライブラリ -> NetCDF ファイル 作るデータ構造 データ解析等 -> rubyインターフェース -> NetCDFライブラリ -> NetCDF ファイル (ruby) | | f2c で変換された DCLライブラリ ● Ruby (堀之内) ruby グループの活動報告 ruby グループのML を立ち上げた! まつもとさん講演会を企画した! ruby に関するいくつかの議論 ruby とは? の 堀之内サマリー なひさんのサマリーメールの紹介 gtrb 復習・検討 : gtrbの検討 -- 継承はあきらめる 不満だった点は Datum クラスが弱い. 値の書き込みメソッドがない --- 特異メソッドで個別にってのは今いち 数学演算が定義されていない ---> Datumは「賢い」多次元数値配列を基礎に据えるべき (配列とは要素の集合で、個々の要素やサブセットへの アクセスの方法を備えるものである。実体がどこにどう入っ ているかは問わない。だから実体はメモリー上にすらなく て良い。) 定義域の性格が曖昧 (Varは座標変数、さらに言えば可視化範囲の デフォルト設定することを念頭に置いているので、座標変数でない ものは単に持て余している) Gridは長さの列だけでいいとは思えない。そもそもこれは必要か? Datum のレベルでは要らなくて、ClassDataとかになってから必要 なら導入すべきものじゃないか。 データの検討 まず配列をちゃんと考えなあかん 配列って何? 要素へのアクセスが個別でもサブセットでもできるもの. 配列に対してどういう操作をしたいか, 何が欲しいかを考えよう. 実際に作りながら考えてみましょう. 今のところの要求は, (1) 多彩なサブセット指定をできるようにしたい 便利な切り出し, 演算 いろいろな指定法 要素のインデックス 範囲 with or without a step ラバー次元 終端、終端から後ろ向き数え(-1,-2,-3,...) これは議論の的 サイクリック属性 (2) 賢く演算がされるようになっていて欲しい 例えば, 欠損値のところはよけて a+b ができるとか (3) 浮動小数点ベタ並べ領域を持つ配列クラスが欲しい なぜかというと浮動小数点を持つ実数一個一個をオブジェクトと して扱ってしまうと(ruby では普通そうなっている. ruby では 万物がobject だから), 実際には使い物にならんと思われるから: パフォーマンスが悪い、メモリ食う, ベクトル化に不便etc 浮動小数点ベタ並べ領域を持つ配列クラスの「定義」は C でやっ てやれば良い. 具体的には, 関数を C で定義して(C の引数として実数値をとる関数に ruby 用のインターフェースをつける. 構造体を引数として取れる関数を 作る.), ruby でその関数を使うようにすれば良い. (4) 各次元がサイクリックかどうか指定できるようにしたい 例えば, サイクリック指定されると, A[0]=A[10]=A[-10], A[-2..2]==A[8..12]==A[8..9]&A[0..2] とかなっているようにしたい. この段階でのコメント (1) ruby のプログラムって何か恐いぞ(一井) 例えば, 既に存在するクラス(組み込みクラスでも自分が定義したクラスでも) に属性を追加したりできてしまうので, プログラムの最初から最後まで 見ないと何が起こったかわからないよね. クラスの属性を変えないように保護する方法ってあるんでしょうか? (2) 全部クラスにするんだったら, 最終的には温度クラス, 密度クラス… って定義することになるの?(一井) 少なくとも, 密度と温度を足そうとしたら文句を言って 欲しいのでは? 多次元配列の作成 上の不満を解消すべく, 以下のような配列(クラス)を定義した. (1) 数値型1次元配列 NArray 組み込みの配列 Array を継承 演算子の再定義 : +は足し算、*は掛け算 sin, cos, exp など (Mathモジュールにある関数を実装) その他 (abs,sumなど)。もちろんもとの Array のメソッドたちは継 承されている(lengthとか) 初期化 NArray.new(10) # 長さ10の配列を確保(中身は[nil,nil,..]) おまけ NArray.indgen(10) # 初期化して、等間隔データ代入([0,1,2..]) (2) 数値型多次元配列 NMDArray 初期化命令 a=NMDArray.new(3,4,2) サブセット [], []= a[2..-1,{0..-1,2},0] なお、長さ1の次元も保つ。消すには trim を使え コピー b=a.dclone # deep clone(copy) 注 : 中身も全てそっくりそのまま duplicate する. (ruby の dup は第一層目しか duplicate しない : こういうのを shallow な clone と言う.) 一次元配列により中身設定 import1d a.import1d(NArray.indgen(a.length)) 自動フォーマット出力 a.prt [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23] 転置 transpose # 次元引っくり返し transpose([1,2,0]) # 第1次元(次元0)を一番最後に 変形 rebin b=a.rebin(6,4) # 次元構成を変形[3,4,2]->[6,4] 次元挿入 insert_dim b=a.insert_dim([0,100]) 次元0(第1次元)に 長さ100の次元を挿入。今までの次元は後 ろにずれ、第一次元は各要素同じ値をとる。 lat = NMDArray.indgen(nlat) lat_expanded = lat.insert_dim([0,nlon]) 中身を一次元配列として取り出す to_a 長さ1の次元を消す a.trim! ; b=a.trim 最大最小 max min 全データ数 length 次元の形 shape # a.shape で [3,4,2] 次元数 ndims rank リニアに変化する値で埋める span indgen spanは通常のメソッド、indgenはクラスメ ソッドで初期化も行なう 数学関数 sin cos tan exp log log10 sqrt ldexp atan2 演算子 + - * / ** 差分 dif(次元) 次元は 0,1,2.. で指定。複数可。 a.dif(1) == a[0..-1, 1..-1, 0..-1] - a[0..-1, 0..-2, 0..-1] よってサイズが1減る 中央値 zcen(次元) となりあう要素の平均。サイズが1減る 中心差分 cdif(次元) 端以外では一つ前と後で差分。 端では端とそのとなりで差分。これで形は保存。 サイクリック差分 cycdif 端点を繋ぐ 配列を繋ぐ concat(次元) 次元は一個のみ指定可 a.concat(b,2) -- aとbを第3次元めで繋ぐ。 結果の第3次元目は前半を a より後半を b から サイクリックに配列を伸す cyc_extend --- concatの簡単な応用 シフト shift (3) 欠損値処理つき多次元数値配列 VNMDArray NMDArrayを継承。(従って諸機能は自動的に使える) データの有効範囲を設定できる。(その外側では正常データとは見な されない。足し算掛け算等々は適用されない) しかし肝心の欠損値処理は実は未実装。 コメント : データは, 各数値が valid か invalid かを示す フラグのリストも持っていた方が良いんじゃないか? (豊田) (4) 多次元「物理」データ PMDArray VNMDArrayを継承。(従って諸機能は自動的に使える。ただし、rebin は使えなくした) 名前と単位、さらに各次元の名前をもつ。 任意の属性(key(名前)と値の組)を設定できる。 再定義: 初期化 引数=(名前, 単位, {次元名,次元長},..) + - / * 自動展開 if 次元が異なる insert_dim 引数が [dim,len] でなく [dim,{name,len}] 新機能: 名前、単位、属性の書き込み読み出し (5) 自己記述型スカラー「長方形」グリッドデータ SData 多次元の主変数を一つ、一次元の「軸」変数を次元の個数だけ持つ。 これらはすべて PMDArray のオブジェクト。 初期化 引数=(main, 軸1, 軸2,...) --- 各々 PMDArray オブジェクト サブセット [], []= NMDArrayと同じ記法で 形, 名前, 単位 etc. shape, name, units, etc. 主変数取り出し main 軸変数取り出し ax(次元) コンター cont 数学演算子 + - * / ** 数学関数 NMDArrayと同様(未実装) 微分 deriv based on dif cderiv based on cdif その他 NMDArray の機能のうちこのクラスになじむものは継承される 応用例 絶対渦度計算 : 微分の計算ができました. 今後の展開 我々が扱いたい NetCDF ファイルとどう compatible にしていくか? 欠損値処理 memory management ● データ構造 (石渡) NetCDF によるデータ表現に関する叩き台は以下の通り. ===================================================================== lon_length = 5 : 各リストの長さ lat_length = 5 lonwgt_length = 5 latwgt_length = 5 // 素データ その 1 float T(lon_length,lat_length) : これで型・長さは指定される. date = 1999,03,09 作成日付 user = 'momoko' 作成者名 reference = '実験番号etc' データ生成情報 memo = 'メモ' その他何でも. long_name = 'Temperature' 記述的名前 units = 'K' 単位 range = 200.0, 450.0 上限下限の目安 valid_range = 0.0, 1000.0 有効範囲 missing_value = -999 欠損値 represent = 'point' 空間代表性. 一点のpoint value は point, cell の代表値は cell とか 以下は要らないよね? / cordinate = 'Longitude', 'Latitude' 座標情報 : 第 n 次元の座標は何か / directionction = 正方向 1 なら昇順, 2 なら降順とか. / cordinfo = 'Longitude weight', 'Latitude weight ' 決め方情報. 点 x_1 が持つべきウェート 以上は要らないよね? // 素データ その 2 float lon(lon_length) date = 1999,03,09 user = 'momoko' reference = 'test-run-01' memo = '' long_name = 'Londitude' units = 'degree' range = 0.0, 360.0 valid_range = 0.0, 360.0 miss = -999 direction = 1 1 なら座標正方向は「添字」が大きい方でかつ cyclic でない 2 なら座標正方向は「添字」が小さい方でかつ cyclic でない 3 なら座標正方向は「添字」が大きい方でかつ cyclic である, とか represent = 'point' // 素データ その 3 float lat(lat_length) date = 1999,03,09 user = 'momoko' reference = 'test-run-01' memo = '' long_name = 'Latitude' units = 'degree' range = -90.0, 90.0 valid_range = -90.0, 90.0 miss = -999 direction = 1 represent = 'point' // 素データ その 4 float lonwgt(lonwgt_length) date = 1999,03,09 user = 'momoko' reference = 'test-run-01' memo = '' long_name = 'Londitude weight' units = 'degree' range = 0.0, 360.0 valid_range = 0.0, 360.0 miss = -999 direction = 1 represent = 'point' // 素データ その 5 float latwgt(latwgt_length) date = 1999,03,09 user = 'momoko' reference = 'test-run-01' memo = '' long_name = 'Latitude weight' units = 'degree' range = 0.0, 180.0 valid_range = 0.0, 180.0 miss = -999 direction = 1 represent = 'point' // データの束ね方情報 date = 1999,03,09 user = 'momoko' reference = 'test-run-01' cordinate = '2-dimensional shperical coordinate' 座標の種類 (x,y,z) はどういう座標か? 例えば 3 次元緯度経度座標, ランダムデータなど. これは「座標の名前」をあらわすキーワード だけ書くことにしておいて良いのか??? cyclic であることの情報はどうしよう? DREL = "Temperature", "Latitude", "Latitude", "Londitude weight", "Latitude weight" 素データの関係 major な変数はどれか. major な変数の第一座標, 第二座標… はどれか. 第一座標, 第二座標… の重みはどれか. map_info = "Mercatore" デフォルトの図を描くための情報 3 次元球面プロットをするか, メルカトル図法の地図 にするか? など. 場合によっては, 座標の基底やメトリックテンソルに 関する情報も必要になる? // 以下データ T = 250.0, 260.0, 270.0, 280.0, 290.0, 250.0, 260.0, 270.0, 280.0, 290.0, 250.0, 260.0, 270.0, 280.0, 290.0, 250.0, 260.0, 270.0, 280.0, 290.0, 250.0, 260.0, 270.0, 280.0, 290.0 lon = 0.0, 72.0, 144.0, 216.0, 288.0 lat = -90.0, -45.0, 0.0, 45.0, 90.0 lonwgt = 72.0, 72.0, 72.0, 72.0, 72.0 latwgt = 42.5, 45.0, 45.0, 45.0, 22.5 ● 宿題 NetCDF ファイルの仕様を決めることが急務ですが, 進んでおりません. NetCDF コンベンション, ruby(C) インターフェース, f90 インターフェース 等などの観点から然るべき NetCDF ファイル の中身を決めなければなり ません. 皆さん, あらゆる角度から意見をください.