From: Markus <markus@...>
Date: 2004-10-14T01:20:04+09:00
Subject: Re: "nan".to_f ?

On Wed, 2004-10-13 at 05:38, Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: "nan".to_f ?"
>     on Wed, 13 Oct 2004 21:18:38 +0900, Markus <markus@reality.com> writes:
> 
> |> It's not valid string representation of a float.
> |
> |      Then why does:
> |
> |x = 0.0/0.0
> |x.class      #Float
> |x.to_s	     #NaN
> |
> |      If "NaN" is not the valid string representation of a Float, why
> |does calling Float#to_s return it?
> 
> Although we can tell whether a float value is NaN by using isnan(),
> but as far as I know there's no portably way to generate NaN.  I think
> it's not guaranteed that 0.0/0.0 generate NaN.
> 
> If I'm wrong, feel free to correct me.

     No, so far as I know you are correct (at as far as math operations
go).  There was another sub-thread on this topic regarding the
assumption that 0.0/0.0 could be PosInf, NegInf, Inf, or NaN.

     I believe there are defined binary representation of IEEE NaNs, so
one could be constructed.  (See, for example 

http://www.psc.edu/general/software/packages/ieee/ieee.html 

), which I suspect is how the libs do it.

     If we could count on 0.0/0.0 to always produce NaN, I believe the
original poster's goal could be met by writing something like:

        class String
            def to_i
                 Integer(self) rescue 0.0/0.0
                 end
            end
        
...although this may not be as general as he needed.

-- Markus