ruby-dev

むらたです．

2008/4/10 Tadayoshi Funaba <tadf@dotrb.org>:
>  たとえば、今現在のやりかたでは、Rational の速度は、Fixnum、Bignum、VM
>  の速度の限界を越えられません。Bignum は、もっと速くなる可能性があると
>  思いますが、それをせずに、Rational が自前で、Bignum を持つということも
>  可能だと思います。
>
>  こういう考えを完全に否定はしませんが、やはりいびつな進化という感じがし
>  ます。

私にはいびつな進化という感じはしません．むしろ，せっかく C で実装できるのに
なぜ最適化できることを最適化しないのか不思議なくらいです．

ふなばさんは，Rational は Bignum や Fixnum 以外の整数クラスも保持できる
必要があるとお考えなのでしょうか？もしそうだとすると，現状の Rational
の方がいびつな感じがします．

例えば GMP の多倍長整数をラップしたクラスとして GMPInt のようなものが
あったとして，これを使った Rational を作ることを考えましょう．
1/2 のように簡単に記述可能な数でも計算過程によっては，GMPInt で構成される
Rational を明示的に，Rational(GMPInt(1), GMPInt(2)) のようにして
生成しなければならないわけです．

もちろん，GMPInt で構成された Rational と Fixnum で構成された Rational 同士
の演算は coerce できちんと処理されるはずです．それでも，少なくとも一つは
Rational(GMPInt(1), GMPInt(2)) のように生成する必要があります．

それならむしろ，Rational[GMPInt] のような方法で，要素クラスが指定された
Rational クラスを生成し，これを用いて有理数を表現できるようにする方が，
私はきれいに感じます．そうでないなら，組み込みの Rational は Fixnum
もしくは Bignum で構成されるものであると決定してしまうほうが
良いと思いますが如何でしょう？

もしこの意見に反対されるなら，例えば，分子が GMPInt で分母が Bignum
であるような Rational が作れる必要性があるかどうか考えてみてください．
(分子が GMPInt，分母が Fixnum という組合せは有り得ると思います)

>  拡張ライブラリを書く人にとっても、ComplexFloat だけつかうと決めてしま
>  えば簡単かもしれませんが、より一般的なものを提供するならば、逆に複雑に
>  なってしまいます。

そのような複雑性は API を工夫することである程度防ぐことは可能でしょう．

>  Complex 内で、C の Complex をつかうことはあり得る、と思いますが、それ
>  だけのことをする価値があるのか、今のところわかりません。

C の _Complex 型と複素関数群は C99 で国際標準規格になっています．

-- 
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

Thread

Prev Next

In This Thread

Prev Next