From: Tadashi Saito Date: 2008-03-29T01:36:50+09:00 Subject: [ruby-dev:34176] Re: Complex組み込み 斎藤と申します。鋭いかは分かりませんが、できるだけ短めに別角度のツッコミを。 On Fri, 28 Mar 2008 01:52:09 +0900 Masahiro TANAKA wrote: > (2) CやFORTRANの複素数型をラップした、実部・虚部がdouble型の複素数クラス 上記案は、互換性の観点では鵜呑みにするのは難しそうですが、それ以外の点でも あまりうれしくないかもしれません。というのも、そこまでしなくても > a. 速度で格段に有利。 になり得るからです。(sizeof(VALUE)*8 == 64bitマシン限定ですが) 笹田さんが 以前からおっしゃっていて、先日発表なさった「Float埋め込み」がマージされれば 「何もしなくても」現状のComplexのままで高速になると思います。 Complexインスタンス本体は include/ruby/ruby.h で struct RComplex { struct RBasic basic; VALUE real; VALUE image; }; と宣言されていますが、笹田さんの方法ですと既存のRubyスクリプトのみならず、 API (DOUBLE2NUM()/RFLOAT_VALUE()) を利用してFloat(== double)を利用している Cプログラムもすべて、その高速化の恩恵にあずかれるからです (よね?)。 # 上記Float高速化のマージ以前にも、Complex/Rationalを特化命令を対応させて # 高速化を期待する方法もあります。よね… もう一つ、 > c. 拡張ライブラリからアクセスしやすい。 というのは double d = RCOMPLEX(val)->real; と書ける(かもしれない)から、ということと解釈してよろしいのでしょうか。 もし上記についてならば、マクロを定義して dobule d = RCOMPLEX_REAL(val); とすれば、自分は十分にアクセスしやすく感じますし、タイプ数は逆に減ります。 また1.8と比べて、1.9ではRFOO(obj)でキャストするマクロを用いて直接構造体の メンバを読み取るのは、非推奨になる流れのただ中だと思います。せっかく 統一的なインタフェースが一斉に作られようとしている時に「RFOO(obj)->member」が 必要ならば、「例外的に扱う必要がある」という意味でアクセスしにくく感じます。 よって c にはあまり説得力がないと思うのですが、どうでしょうか。 (自分の解釈が間違っているなら、それがまず悪いので御指摘いただけるとありがたい です ^^;) -- 斎藤ただし