[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dennou-ruby:000114] Re: reading binary files



堀之内です。

北村さん>>
>> Ruby の本も発売されたところで nmd_array を試してみようと思い, 手始めに
>> データの入ったバイナリファイル(とはいっても単なる単精度の数値の固まり
>> でそれ以上の情報は全くない)を読み込んでそれをそのまま contour を引かせ
>> ようとしました.

どうもです。

>> このこと自体は何も考えずにできたのですが, 何も考えずに
>> 
>> volt = PMDArray.new("Barotropic Volticity","1/s",londim,latdim)
>> for i in 0..nlat-1
>>   for j in 0..nlon-1
>>     volt[j,i] = file_data.read(4).unpack('f')
>>   end
>> end
>> 
>> としたのが仇となって, データの読み込みにものすごく時間がかかってしまい
>> ます. 配列の大きさが 256*128 程度なら待てなくもないですが, 512*256 く
>> らいの大きさになると相当(歯磨きができるくらい)待たされたりします.

既にお分かりとは思いますが、volt[j,i] とやると、インデックス[i,j]に相
当する一次元配列の位置はどこかを毎回計算してそこへの代入を行いますから、
相当遅くなります。もともと全て ruby で書かれたライブラリーですから、ど
うしても遅くはなりますが、もしも一辺に代入できたらましにはなるでしょう。
とはいえ、unpack('f') というのはきっと個別に呼ぶ必要があるのですね。そ
れなら、せいぜい工夫できるのは北村さんがやられたように最初は一次元配列
に読み込むぐらいでしょうか、

>> 代わりに NArray の配列で,
>> 
>> tmp = NArray.new(nlon*nlat)
>> for i in 0..nlon*nlat-1
>>   tmp[i] = file_data.read(4).unpack('f')
>> end
>> 
>> とかやるとだいぶ速くなりますが, この時の tmp の中身は,
>> 
>> [1.0, 2.0, 3.0]
>> 
>> みたいのを期待していたのに,
>> 
>> [[1.0],[2.0],[3.0]]
>> 
>> となってしまうので, NMDArray のメソッド import1d をそのまま使うことが
>> できません. また, NMDArray の 1 次元配列への代入も 2 次元配列と同様に
>> 時間がかかります. 

NArray は ruby の Array をそのまま継承しつつ、数学演算の装備と再定義を
行ったものですが、代入部分はいじってないので Array と同じはずです。従っ
て、このようになってしまう理由は、右辺の戻り値がスカラーでなく長さ1の
配列だからでしょう。NMDArrayのほうも恐らく内部のデータ領域には 
[[1.0],[2.0],[3.0]] が入ってるだろうと思います(p voltすればわかります)。
これを回避するには

    tmp[i] = file_data.read(4).unpack('f')[0]

とすれば良いでしょう。NArrayでは代入の再定義はしてないので、期待されな
いもの(数値のスカラー以外のすべて)が代入されているかどうかのチェックは
してません。

なお、unpack('f') が配列を返すということは、実は複数個の浮動小数点をいっ
ぺんに処理できるのではないですか。それならより速くなるはずです。

>> 多次元配列への代入を C で実
>> 装する場合に(最終的にはそうする必要があるとは思うのですが)

そうですね。この辺り実働に加わってくれる人が欲しいなと思います。

>> あと, 本題からは離れますが, インタラクティブ Ruby(irb) を使うと, 電脳
>> ライブラリもインタラクティブに呼べるのは面白いと思いました. 描画に関係
>> するインタフェイスをうまく用意できれば, 適当なデータを図示してその結果
>> を見てから, 次に見たいものを判断して, それを図示するということがすぐに
>> できて便利な気がします.

コンパイル型言語による処理と比べるとこれだけで大部便利になりますね。可
視化機能と多次元配列を装備すればそれだけで IDL と同じ土俵に乗れます。

我々が目指すのはさらに上で、データ構造のフレキシブリティーを出来るだけ
許しつつ共通化することによって、汎用性のあるソフトウェアのインフラを作
ろう (汎用性のあるプログラムが自動的かつ簡単に出来てしまう状況にしたい) 
ということだと認識しております。例えば北村さんが球関数ライブラリーを書
けば、そのまま私が苦労無しに利用できるとかいったことですね。

>> 内容の薄いメールですみません.

いえいえそんなことありません。どうも有難うございました。


堀之内 武                 horinout@xxxxxx
京都大学超高層電波研究センター    611-0011 宇治市五ヶ庄
phone:0774-38-3812                     fax:0774-31-8463