Tadashi Saitoさんは書きました:
> 斎藤と申します。鋭いかは分かりませんが、できるだけ短めに別角度のツッコミを。

考えていなかった観点をご提示いただき、参考になります。
ありがとうございます。

> >   (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プログラムもすべて、その高速化の恩恵にあずかれるからです (よね?)。

なるほど。これだとクラスチェックが余分にかかるくらいでdoubleを取り出せ
ますね。ただ、演算をおこなう場合は、さらにrealのメソッドを呼ぶので、
そのコストが気になりました。

> もう一つ、
> 
> >  c. 拡張ライブラリからアクセスしやすい。
> 
> というのは
>   double d = RCOMPLEX(val)->real;
> と書ける(かもしれない)から、ということと解釈してよろしいのでしょうか。
> 
> もし上記についてならば、マクロを定義して
>   dobule d = RCOMPLEX_REAL(val);
> とすれば、自分は十分にアクセスしやすく感じますし、タイプ数は逆に減ります。

  complex c = RCOMPLEX_VALUE(val);

とできて、(できるんでしょうね)しかもメモリーコピーですむとよい、
と思ったのでした。

> また1.8と比べて、1.9ではRFOO(obj)でキャストするマクロを用いて直接構造体の
> メンバを読み取るのは、非推奨になる流れのただ中だと思います。せっかく
> 統一的なインタフェースが一斉に作られようとしている時に「RFOO(obj)->member」が
> 必要ならば、「例外的に扱う必要がある」という意味でアクセスしにくく感じます。
> 
> よって c にはあまり説得力がないと思うのですが、どうでしょうか。
> (自分の解釈が間違っているなら、それがまず悪いので御指摘いただけるとありがたい
> です ^^;)

こういう情報は、考えたり納得したりする上で重要だと思います。
ありがとうございます。

田中昌宏