原です。

Tadayoshi Funaba さんは書きました:
> で、考えていたんですが、目的は、最速の rational を作ることではなくて、
> よりよい rational で、現 rational を置き換えることだ、と思います。

それを第一の目標としましょう。

> 速度を上げるとか、integral? のようなメソッドを新設するとかは、後でもい
> いんじゃないでしょうか。
> 
> 速度を上げるためにコードを複雑にすると、検証が難しくなります。原さんの 
> rational を見た感じでは、テストは少なくとも今の3、4倍は必要になると考
> えています。拙速な最適化は行き詰まりがちです。

ちょっと誤解があるようですが、私は特異なアルゴリズムでスピードを上げよ
うと思ったりしてなかったんですよ。Stein の GCD のアルゴリズムだけは例外
ですが。

今回新しいメソッドを付け加えようともしていません。integral? は現行の
rational-1.19 の integer? の中身を移そうとしただけです。

さて、

やはり、新 rational のメンテナは、ふなばさんにやっていただけないでしょ
うか?

方針について私とほとんど意見は一致していますし、すでにかなりの作業を
終えられています。現時点でそれが最善だと思います。

> 余計な新機能は入れないことにします。Float#to_r や Rational(string) の
> ような、当然あってよいと合意が得られているものは入れます。

同意です。

> inspect の書式は、現 rational と同じ、new は当面 private で、new!、
> reduce も残したところから始めます。

inspect、new については同意します。
new!、reduce は、ここまでの議論の成果として、廃止でいいじゃないですか?
integral? も後回し。

> 以上のような感じで進めませんか。僕としては、次回の 1.9 リリースの直後
> に拡張ライブラリとして入れることを目指したいです。

いえ、ここは「組み込み」を目指しませんか?昔まつもとさんが、T_RATIONAL
の値をくれる(0x0f?)と言った覚えもあるし。

> ここまで速くならなければならない、という指標があれば教えてください。

私の数学っぽいプログラムが、I/O がないのに処理に10分とか何時間とかかかっ
て、実用になる/ならないのクリティカルなところにいるんですよ。たぶん大
きく Rational の処理速度に依存しているんです。こうして欲しいというのあ
れば、Rational 組み込みが一旦達成された後で提案させていただきます。