ごとけんです

In message "[ruby-math:00085] Re: NaN again"
    on 00/01/20, EGUCHI Osamu <eguchi / shizuokanet.ne.jp> writes:

>あ、今回は問題ないけど long が 64 ビットな場合は、
>問題あるんでしたっけ?

64bitはきちんと定義してあるので大丈夫のはずです。その他の長
さだとどうなるかいまいち分かりませんが一応は考慮してあります。

>全順序集合ではない事や、1.0 / 0.0 → Infinity など
>IEEE754 って『数学』と言う見方でみると、かなり
> ``???'' ではあるんですけど、実施の演算としての
>実行を考えると、妥協の産物としてはうまく整合してると思います。

それには同意します。ただNaNの使い道がそれほど詳しく説明され
てないのは惜しいと思います。いちおう、NaNのフォーマットに余
裕があるのはエラー追跡のためらしいんですけど、現状ではほとん
ど使われてないですよね。

>ご> >どちらかと言うと、1.0 <=> NaN = NaN 説に傾きつつあります。
>ご> >(1.0 - NaN = NaN からの類推、例外は発生しないと言う立場です)
>ご> 
>ご> うーむ、それはそれでよいなぁ。NaNも一応Numericだし。一票入れ
>ご> ときます。
>
>ごとけんさんに賛同いただけると心強いです。

# てれてれ /(^^;;

ともかく、<=> はsortのためであるのでそこでそれなりの例外が出
ればよいでしょうね。また、ほとんど全順序だけど、ちょびっとだ
け全順序でないものに <=> を実装したい場合の手本にもなるでしょ
うし。

>まづ、ちゃんと -0.0 を作れるかを確認してからチェックしないと、、

-0.0 のフォーマットはユニークなので、configureの際は基準とな
るものをビットマップで作るのが良いと思います。またFPU例外を
制御するのが面倒なので比較もビットマップとして行った方が良い
でしょう。参考までにこれらをつけときます。

# isnan() もこんな感じで実装しちゃった方が確実かも。

-- gotoken

#include <string.h> double mzero() { double p1, m1, m0; unsigned char pone[8], mone[8], mzero[8]; int i; p1 = +1.0; m1 = -1.0; memcpy(pone, &p1, 8); memcpy(mone, &m1, 8); for(i=0; i<8; i++) mzero[i] = pone[i] ^ mone[i]; memcpy(&m0, mzero, 8); return m0; } int deqp(x,y) double x,y; { unsigned char xmap[8], ymap[8]; int i; memcpy(xmap, &x, 8); memcpy(ymap, &y, 8); for(i=0; i<8; i++) if(xmap[i] ^ ymap[i]) return 0; return 1; } int mzerop(x) double x; { return deqp(x,mzero()); } // main(){puts(mzerop(-0.0)?"good":"NG");}