ruby-dev

> > BigDecimal が閉じてる、というのは、BigDecimal の仕様を読んで感じること
> ということで、仕様を読んで意図は感じていただいたということで…
> 
> > です。他の言語でもそうですが、整数だけつかう、浮動小数点数だけつかう、
> > ということはないわけで、そういうものが一体となって、計算をこなしている
> > と思います。
> 自分としては「そういうものが一体となって」で「閉じている」と表現した訳です。

よくわかりませんが、

> きているのでは？　複数クラスにまたがるより、本来一つのクラス
> 内で閉じていたほうが自然と思います。

ひとつのクラス内で閉じているわけですよね。

> 仕様は熟知されているようなので、truncate の例を出します（他も同じです）

熟知していませんが。

> 　require "bigdecimal"
> 　a=BigDecimal("123.456") # ==> 0.123456E3
> 　a.truncate              #  1) ==> 0.123E3
> 　a.truncate(0)          #　2)==> 0.123E3
> 　a.truncate(1)          #　3) ==> 0.1234E3
> 　a.truncate(-1)        #  4)==> 0.12E3
> この「拡張」がおかしいですか？

んー、たぶん、そこは間違っていたと思います。拡張ではなく、まったくの独
自仕様です。

> 私は、これこそ「売り（任意精度）」と思ってるんですけどねぇ。
> ３）のケースではＩｎｔｅｇｅｒを返すことはできません。

Integer を返すべきだったと思います。そういう機能が必要なら、別にするか、
少なくとも引数なしで呼ばれたら、Integer を返すべきだったと思います。
div とかも同じです。

Float にも BigDecimal にも利用できるコードを書くことは可能だったはずで
す。全てがそうである必要はありませんが、Integer にも Float にも 
BigDecimal にも通用するコード片だって十分な可能性があります。

振舞いに統一性がないと、そういうことがやりにくくなります。

今現在、実際には、Complex では、BigDecimal を Complex.generic? ではな
いとして弾いていますが、Complex が Float を受けいれるように、
BigDecimal を受けいれる可能性だってあるのかもしれません。実際、Complex 
が受けいれるに当ってなにか障害があるかわかりませんが、同じ数値クラスに
おける、この統一感のなさは、奨励できるものでもないように感じます。

あくまで同一クラス内で閉じたところで、なに事か成せばよいと考えれば、あ
まり気にならないのかもしれません。今現在、そういう志向であることは間違
いないと思います。それは、どうしてもそうしなければならない理由があるか
らなのかどうか、ちょっとよくわからないんですが。

> > しかしながら、位置付けがどうであれ、BigMath の関数が、モジュール関数で
> > あって、いけない理由がわかりません。あと、Float#to_d が、
> > BigDecimal(self.to_s) なこととか。
> これは特に理由はありません。

では、そうなっていても、よいと。

> > あくまで自信がなく、サンプル的なものであるというなら、いっそインストー
> > ルしないほうがいいのでは?
> いまさらという気もしないでもありませんが「自信がなく」ということでは
> ありません。　「計算できる」という例です。

自信はないことはないが、現状版を押し付ける勇気はないので、例に過ぎない
ということですか。

僕もよく失敗するのですが、自分が思うようにはつかってもらえないものなの
で、インストールされないようにしたほうがいいかもしれません。