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

>>> In message [ruby-math:00072] Re: NaN again
    On Wed, 19 Jan 2000 03:52:03 +0900 (JST), gotoken / math.sci.hokudai.ac.jp (GOTO Kentaro) said:

ご> ごとけんです
ご> 
ご> In message "[ruby-math:00061] Re: NaN again"
ご>     on 00/01/18, EGUCHI Osamu <eguchi / shizuokanet.ne.jp> writes:

ご> そうです。 [-0.0].pack("G")[0][7] == 0 と同じです。
ご> 
ご> >pack/unpack って最後の手段的な感じですが、他にはどうも
ご> >方法が思い付かないです。(copysign() は ruby にないし、、)
ご> 
ご> たぶん他には独立した検査方法は無いと思います。
ご> 
ご> # しかし、こんなにお手軽に double のフォーマットが調べられる
ご> # 言語もあるまい(←自画自賛 :-)

pack/unpack を使うと、エンディアンも気にしなくて良いし、
激しくビット思考な処理を、移植性を保ったまま実現でいるのが
良いですね。

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

ご> >  NaN と何を比較しても不一致
ご> >と言う面白い性質を ruby で体験できなくなるとは言えます。
ご> >とはいえ <=> が NaN を伴った場合との不統一感は否めませんね。
ご> 
ご> NaN だけのために Float が全順序集合でなくなるというのも結構
ご> すごい仕様ではありますね、IEEE754って。quiet NaN の由来を考
ご> えてみるに、静的に検査できることが目的だったのですから、NaN 
ご> を含むpositiveな(つまり否定形でない)比較はすべて false を返
ご> すという仕様でも悪くないかも知れません。

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

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

ごとけんさんに賛同いただけると心強いです。

仮に、これが採用されると、例えば、 ary#sort では、、

  % ruby -e 'p [1.0, 1.0%0, 5.9, -8.2, ?Z].sort'
  /var/tmp//rbk46230:1:in `<=>': comparing NaN (FloatDomainError)
	  from /var/tmp//rbk46230:1:in `sort'
	  from /var/tmp//rbk46230:1
が

  % ./ruby -e 'p [1.0, 1.0%0, 5.9, -8.2, ?Z].sort'
  -e:1:in `sort': float NaN out of rang of integer (TypeError)
          from -e:1

となります。
どちらも、NaN が紛れ込んでいた事は判ると思います。

ご> >  % ./ruby -e 'p "%10.1E" % -0.0'
ご> >  "  -0.0E+00"
ご> >
ご> >こんな事は出来ましたが、、
ご> >
ご> > + -0.0 の検出方法に問題を感じる
ご> > + 元々ちゃんと -0.0 を表示できる場合も実行している
ご> >   (configure で検出すべき?)
ご> > + -0.0 を -1.0 にすり替えて '1' => '0' なんてあんまりだ!
ご> 
ご> これでいいんじゃないですか?? ただ、すくなくとも configure で
ご> の検出はしたほうがよいでしょうね。

VC もおなじバグがあるようなので、ちょっと真剣に考えてみます。

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

	えぐち