From: keiju@... (=?ISO-2022-JP?B?GyRCQFBETTc9PHkbKEI=?=)
Date: 2008-10-03T21:52:39+09:00
Subject: [ruby-dev:36657] Re: {Complex,Rational}::Unify

けいじゅ＠いしつかです.

In [ruby-dev :36654 ] the message: "[ruby-dev:36654] Re:
{Complex,Rational}::Unify ", on Oct/02 20:12(JST) Tadayoshi Funaba
writes:

>では、暫くはこれでいいとして、ゆっくりと 2.0 までの中期的な対策について
>考えましょう。

松本さんが交渉してくれると言っているので, できれば, 今回のに乗っかると
うれしいのですが. もちろん, あまり時間がないので大掛かりなことはできな
くなると思いますが...

>石塚さんの中でそういう結論が出ているのかもしれませんが、僕には判らない
>んです。何度も言いますが、そのあたりから、議論がおかしくなっているので、
>そこは飛せないと思います。

了解. それもそうです.

ただ, 正直言って必要性からではなくて, 私の目論見から来ています.

まず, 普通に mathn が使われるようになって欲しいという思いがありま
す. 言うまでもないことですが, mathnというのは, exact number 間の移動を
自由にするのが目的です. 今でも, RubyはFixnumとBignumで行われていますが, 
それの拡張です. 

では, 現行はどうなっているかというと, Rationalは組み込みになりましたが, 
整数同士の割り算でRationalが生成されるわけでないので, Rationalを使いた
ければ, 明示出来に
  
  Rational(1)/Rational(2)

とかしなくてはならず, 現行のままでは Rational の価値はイマイチで,
mathnがあって価値が発揮できると思います. 

# 状況は, floatも同じですが, 専用のリテラルがある.

ただ, 逆に言うと, mathnは, 割り算の振る舞いが既存の振る舞いと違ってい
ます. 計算上こっちの振る舞いが良いと思っていますが, 既存のライブラリが
動作するとは限らないです(to_intのおかげでだいぶ動きそうですが). で,
mathnがもっと普及すれば, 動かないライブラリがでた場合でも, mathnで動か
ないので, そのライブラリを修正してくださいと, 堂々と言えるぐらいまで広
まって欲しいんですね. 

それと, 今後, Rubyのほうでは, int/int をどうするかの話が出てくると思い
ますが, その選択肢の一つになって欲しいんですね. 

そのためにも, 拡張ライブラリぐらいのパフォーマンスが欲しいと思っている
わけです.

1.9.1でmathnが高パフォーマンスで導入され, 2.0で標準の振る舞いにまで持っ
ていくのが, 私の願望です. 

__
---------------------------------------------------->> 石塚 圭樹 <<---
---------------------------------->> e-mail: keiju@ishitsuka.com <<---