ruby-dev

>   Rational::Unify が定義されているときは、Rational.new(1,1) で Integer
>   を返させたいのだが、スクリプトレベルではそれはできない。そこで、new
>   を禁止し、関数 Rational() を使わせる。そして、関数を用いた
>   Rational(1, 1) では、 Unify が定義されるときは、Rational でなく
>   Integer の 1 が返るようにする。これの仕組みで mathn.rb がスムーズに
>   機能する。

原さんは複雑に考え過ぎてるのでは。僕からすると Unify の存在と new の存
在意義は関係がないです。とにかく Unify があれば、いずれにしても Unify 
されるべきでしょうし。

Rational() と Rational.new の違いは、Rational() は変換器で、
Rational.new は基礎的なコンストラクタということだと思います。原さんの 
rational からもそういう印象を受けるので、基本的に考えていることは同じ
だと思うのですが。

> Rational を内部で使うライブラリで、mathn.rb を include すると、答えは
> 正しいが、処理速度がかなり遅くなるものがあります。そここで、Unify の影
> 響を受けない有理数の生成が欲しいと思ったのです。

しかし、mathn すると無駄な有理数を排除することになるので、ある場面では
有利になりますよね。組みこみにして、数値系としての連携を強化し、リテラ
ルを用意したら、だいぶ違ってくると思います。

どういう数値表現であれ / と div ちゃんとつかいわける、適切なところで 
floor などをつかうなどすれば、あまり無駄なことはないような気がします。
このためにも div や floor の仕様は揃ってないといけないと思いますが。

> しかし、Rational.new(1, 1) の結果が Rational でなくて、Integer になる
> のは気持ち悪い気がしません？new は private のままがいいかなあ。

その感覚はわかりますが、たとえば、Common lisp では、1/1 はリテラルです
が、1 になります。複素数の #c(1 0) も 1 になります。new に固有の課題で
はなく、Rational() や Rational.convert も「変換」しないといけないわけ
ですから、Integer が返るのは変である、といえるかもしれません。

逆に考えて、1 を便宜的に 1/1 や 1/1+0i と表現してもいいのだと考えるの
はどうでしょう。