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

速度を上げるとか、integral? のようなメソッドを新設するとかは、後でもい
いんじゃないでしょうか。

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

今、速度上げるなどの作業で、わかわざハードルを上げる必要があるでしょう
か。ここまで速くならなければならない、という指標があれば教えてください。
今必要なのは、コードの確かさ、保守が可能で、将来の改善の芽を摘ないこと
だと思います。

原さんはもう作業を始めていると思いますが、それは後回しにして、検証等に
注力してもらえないでしょうか。僕のほうも最初は nurat-0.0.4-ho で実験し
たようなコードを入れるつもりはありません。

先ずは、速度は、現 rational より明かに速ければいい、と思います。速くし
たければ、速くできることは証明できたと思います。今、できるだけ速くしな
ければならない、ということはないと思います。

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

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

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