[ruby-dev:5207] Re: Bigfloat [compare to NaN]

えぐち＠エスアンドイー です。

>>> On Wed, 17 Feb 1999 16:52:02 +0900, [e-mail] (石塚圭樹 ) said:

keiju> けいじゅ＠日本ラショナルソフトウェアです.
keiju> 
keiju> In [ruby-dev :5167 ] the message: "[ruby-dev:5167] Re: compare to NaN
keiju> (Re: Re: call for finite/isnan testers) ", on Feb/16 22:55(JST) EGUCHI
keiju> Osamu writes:
keiju> 
keiju> >えぐち＠エスアンドイー です。
...
keiju> >まだ、ゼロの符合に関する配慮が欠けています。
keiju> 
keiju> +1 0 0 と -1 0 0 ってことですかね?

そうです、これ結構面倒です。
いちど @sign * @prov すると、-0 が +0 になってしまう。^^;;;;

keiju> >隠蔽しても良いのですが、 def + とかで、楽しちゃったもので、、
keiju> 
keiju> なるなる. protectedにするか,
keiju> 
keiju> @sign, @prov, @exp = num.instace_eval{[@sign, @prov, @exp]}
keiju> 
keiju> を用いるというてもありますね.

結局、instace_eval が便利なので、これにします。

keiju> >keiju> @provは, 常にPRECだけの桁数を持つBignumなんですね? 確かにその方がよい
keiju> >keiju> に違いない(^^;;;
keiju> >
keiju> >有効数字だけ仮数を充填しておく事で正規化してます。
keiju> 
keiju> ですね. 気がつかなかったなあ...

２進数でこれをやると、ＭＳＢは常に立つのでそれは
立っているものとして扱い、記憶スペースを１ビット節約します。

keiju> >２進数は考えましたが、 to_s があまりにややこしかったので挫折しました。;_;
keiju> 
keiju> そうです? 変わらないと思うんですが...

１０進数にする時に仮数だけでなく指数を繰り込まないと
駄目です(ってあたりまえかぁ)、これと負の指数などを一緒に考えたら
表駆動とかアイディアは出るのですが、何か Ruby で書くのが
自然でない様に思えたからです。(負け惜しみモード)

keiju> >私的には、２進化はＣ言語版になってからのの課題です。
keiju> 
keiju> やはり, 期待して待っていよう(^^;;;
keiju> 
keiju> >keiju> ここどういうつもりですか? って, 私のコードがこうなっていますね(^^;;; 
keiju> >keiju> 昔はこうでなくては駄目だったんですが, 今はこっちの方が良いでしょう:
keiju> >keiju> 
keiju> >keiju>   @sign, @prov, @exp = num.instace_eval{[@sign, @prov, @exp]}
keiju> >
keiju> >え、こんなのあり？
keiju> 
keiju> 今はありなんですね(^^;;; 

使ってみました。

    right, @exp = num.instace_eval{[@sign * @prov, @exp]}

文字列でなく式を、そのインスタンスのコンテキストで
評価するのかぁ、、、、すげーぇ。
＃これもいてれたーなのかなぁ

keiju> 
keiju> >ごろごろ出て来ますね。 @_@
keiju> 
keiju> (^^;;;
keiju> 
keiju> >keiju> >  def <=>(other)
keiju> >keiju> >  def +(other)
keiju> >keiju> >  def -(other)
keiju> >keiju> >  def *(other)
keiju> >keiju> >  def coerce(other)
keiju> >keiju> 
keiju> >keiju> ここなんですが, PRECの違うBigfloatについてまだ考慮がなされていませんね.
keiju> 
keiju> >そうなんです。
keiju> >実は、prov の大きい方に合わせるというアイディアを持っていてのですが、
keiju> >実装には移ってないです。
keiju> 
keiju> provですか??

この実装では(正規化されてるので)精度はおおむね prov.size ですので。。。
って Bignum に完全に依存していますが。。

keiju> そういえば,
keiju> 
keiju>   def +(other)
keiju>     case other
keiju>     when Bigfloat
keiju>       #break
keiju>     when Integer, Rational, Float
keiju>       other = Bigfloat(other)
keiju>                             ^^^^
keiju> 
keiju> ってなっていますよね. 有効桁数の低いものから高いものにしても意味がない
keiju> ので, 逆の方が良いと思っているんですが?

FloatDomainError を出していいのであれば、そうします。

keiju> Bigfloat間でも PRECの低い方にあわせた方が良いと思っているんですが.

これだと、明示的に精度向上の為の型変換をしないと、どんどん
精度が計算を繰り返すと低くなりませんか？

私は C の

	double + float => double

の様なイメージをもっています。

keiju> >keiju> # でも, モジュールにするとこれでは駄目でもうちょっと工夫が必要ですが...
keiju> >
keiju> >モジュールにすると、どんな使い道が出るのか今一つ判らないのですが、
keiju> 
keiju> 抽象クラスだから, モジュールでもいいかなと思ったぐらいです. 無理に拘ら
keiju> なくても良いと思います.

さきほどの、平方根などはモジュール向きですね。
でも、四則はや変換はモジュールにはなりにくいかなぁ、、
早めに分けないとだめ？

keiju> >自由な精度(と基数？)の浮動小数点クラスが簡単に作れると良いですね。
keiju> 
keiju> これは, どちらでも可能です.

精度と基数をクラス持ちにするか、インスタンス持ちにするか
あるいは、どちらも選択できるようにするかを含めて、
まだ悩む余地がありますね。

keiju> >keiju> また, インスタンスがprecをもつけれども, 演算ではprecの違いは考えず変換
keiju> >keiju> はcoerceで対応するというのもあるかなと... この方法だとクラスは1つにな
keiju> >keiju> ります.

keiju> でも, 最後の案は, Presicionと相性がすごく悪いのでやめましょう.
keiju> Presicionはクラスが1つの確定した精度を持たないと困るみたいです.
keiju> 
keiju> # ですよね? >> ごとけんさん

とすると、クラスの定数と言う事ですね。

うむうむ。。。。

	えぐち