原です。

>けいじゅ@日本ラショナルソフトウェアです.

> >rational のパフォーマンスで一番気になるのは、演算を行うたびに gcd 
> >の計算をするところですよね。gcd ってのはかなり複雑な計算なんで、
> >それが Integer#/ の様な基礎的な位置にある演算子で、特に意識しない
> >まま始まってしまうってのがやや気持ち悪いわけです。
>
>でも, gcdって割り算の効率とほとんど同じでないですか? 手元の本だと
>
>除算: O(n * log n * log log n)
>gcd:  O(n * (log n)**2 * log log n)

なるほど gcd は除算の log n 倍ですか、それは感覚的に分かります。
っていうか、除算ってそんなにコスト高いですか?びっくりだなあ。
それを考えると log n って小さい。ううむ、これは大きいなあ。


> >流れからすると、石塚さんと正木さんは後者ですね。後者だとすると例
> >えば 1/3 + 2/3 も int の 1 になるわけですね。それはちょっと気持ち
> >悪い。
>
>私は一応後者を推していますが、「int/int -> int」派の人も前者なら受入れ可
>能だと言うなら、前者でもかまいません.

石塚さんは本当に前者でもいいんですか? 2 / 1 が Rational の 2 で
もいいの?


> > >3. matrix.det みたいなものは, 今のメカニズムではどうやっても綺麗に解決しそ
> > >   うにない.
> >
> >これは綺麗に解決しないでいいのではないかなあ。
> >
> >デフォルトの det は効率が悪くても割り算を利用しない方法を提供して、
>
>うーん. そういう手もあるんでしょうが... 多項式が要素になると割り算してい
>るとまずいんですかね?

多項式の時には有理関数体まで引き上げて計算するんですか。そうする
と、また加減乗除で gcd の計算が出てきて、、、効率はどうなんだろ
う。

matrix.det の matrix を一般の要素を持つとせず、組み込みの Numeric
下の要素のみを対象とすると限定して、かつ、有理数も組み込みにする
ならば、int 要素の matrix を有理数体上で計算するのは、もっともな
選択である気がします。そうではなく、matrix の要素としてなんでも
あり(例えば要素として正方行列を取るとか)として det を定義する
なら、素朴な方法しかないですよね。


> > >4. 今回のcomplex#**なんかも根にはこれがある. 
> >
> >a ** b の話は / とは大分違いますね。** は T op T -> T に拘る必要
> >はないですよね。
>
> >環の枠組みで決まる場合、つまり b が非負整数、a が 1、a が -1 で b 
> >が分母が奇数の有理数、、、などの場合は自明な値を返すべきだけど、
> >それ以外、例えば 2**(-1) の場合は、例外にする(1 / 2 と解釈しない)
> >かあるいは 0 にする、というのはありだと思います。これを「不自然」
> >という考え方もありますが、不自然なのは 2**(-1) の「値」ではなく、
> >整数のカテゴリで 2**(-1) を「させる事」の方なんだ、という考え方を
> >します。
> >
> >(負のfloat) ** float は、require "complex" しても NaN のまま、あ
> >るいは例外でいいと思います。それはやはり「本来は複素数」という考
> >えをあまりしたくないからです。「本来」って何?と疑問に思います。
> >Complex(負のfloat) ** float がそれなりの値を返したとしても、それ
> >は本来の値を返したというより、むしろ Complex の仕様に過ぎないと考え
> >た方がいいのではないでしょうか。もちろんその仕様はなるべく「自然」
> >なものを選ぶべきだけど、そもそも「本来」や「自然」の定義が疑わし
> >いわけだから、そんなに拘ることもないと思う訳です。
>
>ここの前の3つの段落意見が発散しているような(^^;;;

すいません。complex#** 関係について「雑感」を述べてしまいました。
要約すると「n 個の x の積に x ** n を用いる。後は適宜。」という
事なんですけど。要約しすぎか。(^^;


> >ところでこれも別の話だけど、平方根を越えない最大の整数を返す、
> >Integer.sqrt ってのもあると便利かなあ。Math.sqrt(2) を 2 乗したと
> >き 2 より大きいのか小さいのか、その情報が需要な局面てのもあるから。
>
>Integer.sqrtは高速に計算できそうですね. ビットシフトするだけだから.

それは是非ほしいです。


> >いろんな事言ってますが(^^;、結局私の意見としては、「int/int ->
> >rational でがんばってみるのもいいかもしれないが、int/int -> int 
> >という現状の仕様のままでも、それはいささかも Ruby の価値を落とし
> >てはいない(数学的にも)。Rational は早く C で書き直して組み込み
> >にして頂戴、よろしくお願いします。」というものです。
>
>結論としては、rationalでも(型固定なら?)よいよってことですね?

いや、型固定にそんなに拘っているわけでもないんだけど。(元々 Ruby 
が int/int->rational だったら、今よりもっと Ruby を好んでいたか
もしれません。ますます言ってる事がバラバラ。)

しかし、もしそうなったら、Rational#to_int が定義されたとしても、
array[i/2] と書いていた所をつい効率を考えて全部 array[i.div 2]
などと書き直したくなるわけですよ。それでもいい?

私は、現状維持に1票いれるけど、多くの人がそしてまつもとさん
が rational にするというなら、それでもいいと思います。その最
期のちがった最後の一人がなかなかウンと言わない気がするけど。