原です。

お久しぶりです。

私は、石塚さんの [ruby-math:00597] での det に関する

 >というのも、ポリモルフィズムと関係があります。つまり、現行では、数値関連
 >のクラスの``/''演算子のうちint/int だけが違う振る舞いを持っていて、ポリ
 >モルフィズムの嬉しさ半減、さらに悪いことには思ってもいない振る舞いをするっ
 >てことです。
 >
 >つまり、本来であれば出来るはずのアルゴリズムの再利用性が半減しているわけ
 >です。典型的な例が、Matrix#detの例でしょう。Matrix#detで使っているアルゴ
 >リズムは、ある程度普遍的なもの、つまり、数値であれば適応可能なアルゴリズ
 >ムになっています。ところが、int/int の振る舞いが除算でなくて整除になって
 >いるので、intが入っているとちゃんと計算できなくなると。正木さんも同様な
 >例を出してくれましたが、こういったものはいっぱいあるわけです。

の説明が int/int->rational 派の意見では最も説得力を感じました。確かに
基本的な演算、メソッドは、将来のポリモルフィズムの有効性が生かされるよ
う、統一性のある仕様を持ってほしいですねえ。

でも、ここではやはり、まつもとさんの「『普通の数値』というイメージは幻
想ではないか」という説([ruby-math:00599])に肩入れしたい気がします。
例えば、石塚さんの [ruby-math:00614] での例 mean つまり

 >  def mean(*numary)
 >    sum = 0
 >    for n in numary
 >      sum += n
 >    end
 >    sum / numary.size
 >  end

で mean(1, 2) が 1 となって意図しない値を返すという話ですが、まつもと
さんが [ruby-math:00615] でも言っているように、これは 1 でよい、という
人も少なからずいると思います。これは、仕様を知っていれば、その仕様を利
用しようとする、という当たり前の事なんですが。もちろん、mean というメ
ソッド名から、3/2 を期待する人や 1.5 を期待する人は、多くいるでしょう
けど。

これで思い出したけれど、要素の総和 sum が Array でなかなか実装されない
一つの理由に 0 個の要素で何を返すべきか、定義できないというのがありま
したね。これは、数学の総和を表すΣはいわばメタ数学レベルの記号であって、
扱われる体系において適宜定義されるものであることと無関係ではないわけで
す。つまり数学的には写像は定義域をはっきりさせないといけないのだけれど、
Σは、局所的に意味がはっきりしていればいいじゃないか、という様なしろも
のです。

mean はこれに加えて値域もはっきりさせないといけない、という例ですね。
もっとも、定義域と値域だけではまだ不十分で、最終的には関数の仕様をきち
んと定義して明らかにしておくべき、という当たり前の結論になってしまう。
他の例では gcd(6*x*y, 9*x*y) は、整数上の多項式と考えれば、3*x*y だが、
有理数上の多項式としては x*y、Q(y)係数の x の多項式としては x となり、
gcd の引数だけで決まるわけではないわけです。

で、私の今の所の考えは、ポリモルフィズムの有効性を高める方向は大事にし
たいが、数学的な対象を扱う上では、しばしば破綻するので、適当にバランス
を取るべし、というものです。(^^;

具体的には、例えば Matrix#det を考えてみます。これは sum の話にかなり
似ていて、行列の直和の det は det の積になりますから、(0, 0) 行列の 
det は、考えている系の積の単位元であるべきなのに、0 要素の det は何を
返してよいかわからない。つまり普通使われている「行列式」はΣと同じく、
数学的な意味での写像ではないわけです。

det は mean とはちょっと性質が違いますね。det で割り算を使うのは効率の
ためであり、mean が割り算をするのは本質的です。整数要素の det の場合、
掃き出し法を使う使わないで、あまりにも効率の違うので、やっぱり定義通り
に計算するのはかなり気持ち悪い、という所が問題なわけです。

そこで私のこのケースでの新たな提案ですが、det の要素が全て整数ならそれ
を有理数か有理数もどきに変換して、やはり掃き出し法で結果を求め、後でま
た整数に戻すのがいいのではないかと思います。

この解決方法は、一見かっこ悪いですが、数学では、環での話を環の商体に持っ
て行って議論したり、更に代数的な閉体まで持って行ったりするのは、しばし
ばやる手法ですよね。整数を p 進体や代数体で考えたり、3 次方程式の実数
解を複素数で表現したり、多項式を有理関数体で考えたりとか、数え切れない
ほど例があります。

つまり、整数の問題を有理数体で解決して整数に戻したりすることは、これが
本来、有理数の問題だからそうするのではなく、有理数をツールとして用いて
いるわけで、これを不細工と考える必要はないのではないか。この方法は、最
初に各成分がどのクラスに属するかチェックする所がダサイわけだけど、
「det の本来」というものを考えるとするなら、どの環の上で考えるのかを何
らかの形で最初から指定すべきでしょう。それを指定しない、とにかくユーザー
が比較的便利に使える汎用の Matrix#det を定義したいのなら、内部でのポリ
モルフィズム利用に見切りをつけて場合分けを厭うべきではないのではない
か、、、というのが私の説です。

この様に「数」を相対的に見る立場がどの程度一般に通用する考え方かちょっ
とわかりません。でも計算機でプログラミングをする人には受け入れやすいみ
たいだけど。多分 20 世紀以前の人間にはあまりこういう発想はなかったと思
います。実は今時の数学屋の中でも、この、数をツールとしてローカルに用い
るという発想は、代数系の人には受け入れやすく、解析系の人にはイマイチ受
けないという傾向があるみたいですね。まあ、基本的には、使えるものなら何
でも使うわけですが。

私は、あるブロックの中でリテラルな整数 1 などを Rational と解釈する様
な環境が作れたら、今回の問題はかなり解消すると思っているのだけど、
"Behavior" って、こういう用途に使えますかね?