At Tue, 2 Apr 2002 16:16:04 +0900,
石塚圭樹 wrote:
> >Complex/Rationalとも考えてみましょう.
> 
> 考えるといってなんですが... Complex op BigFloat はComplex側で対応するの
> はよいとして、Rational op BigFloat は BigFloat側で対応すべきと思います.
> 
> というのも,
> 
>   Rational op BigFloat -> BigFloat
> 
> になるので, RationalがBigFloatの生成を知っているというのはおかしいと思う
> からです.

 確かに仰るとおりですね。BigFloat 側で対応します。

> ただ, BigFloatからみてもrational.rbを読み込んでもいないのに, Rationalの
> 対応のコードが入っているのも変なので,
> 
>   bigfloat-rational.rb
> 
> のような相互変換のためのメソッドを集めたファイルを別に用意したらどうかと
> 思います。で, bigfloat側はrequireされたときにrationalが既に読み込まれて
> いたら bigloat-rational.rb を読み込み、逆にrationalがrequireされたときに、
> 既にbigfloatが読み込まれていたらbigloat-rational.rbを読み込むと.

 どうなんでしょう。プラグインできる形でうまく分離できますかね?
あるいは、サポートコードが分けるに値するほどかさばるのか、という
問題もありますが。

 仮にも標準添付クラス同士なので、最初からコードは含めておいても
いいような気はします。

> ところで, クラス名の件ですが, BigFloatはあまり良くないのではないかと, 小
> 林さんの言われるように,
> 
>   BigDecimal
> 
> とかのほうがよいのでは? BigFloatはFloatと変換上完全上位互換のある2進系の
> 数であって欲しいです.

 小林さんと直接やりとりしていますが、

	- BigFloat は BigDecimal と改称し、 immutable とする

	- 効率のための入れ物インターフェースは(Numeric でない)
          別クラスで提供する

という方向で検討に入っています。

 rough に入れてしばらく育てるつもりですので、引き続きアイデアや
注文があればよろしくお願いします。

-- 
                     /
                    /__  __            Akinori.org / MUSHA.org
                   / )  )  ) )  /     FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ /  ( (__(  @ iDaemons.org / and.or.jp

"Somewhere out of a memory.. of lighted streets on quiet nights.."