From: Daniel Berger <djberg96@...>
Date: 2005-04-05T05:14:43+09:00
Subject: Re: Math.sqrt(NaN) behaves differently on windows and linux

Guillaume Marcais wrote:
> On Tue, 2005-04-05 at 02:50 +0900, Berger, Daniel wrote:
> > From what I'm reading at
> > http://www.opengroup.org/onlinepubs/009695399/functions/sqrt.html,
it
> > appears that in this case, Windows is, in fact, doing the right
thing
> > (though see below).  From the text:
> >
> > "For finite values of x < -0, a domain error shall occur, and
either a
> > NaN (if supported), or an implementation-defined value shall be
> > returned."
>
> It seems to me that the the relevant part in the text is:
>
> "If x is NaN, a NaN shall be returned."
>
> So the *nix implementation is correct and the Windows one is not.

I think it's open for debate.  It causes a ZeroDivision error on both
Perl and Python if we want to look at what other languages do.

> > It looks to me like *nix is only returning NaN, but isn't actually
> > raising an error while Windows is raising an error, but is not
returning
> > NaN.
>
> Well, there is a problem here between the way C and Ruby raise error.
In
> C, the eerno variable is set and a specific value is returned. In
Ruby,
> when an error is raised, the call doesn't return and the call stack
is
> traversed to find the next rescue clause. So in Ruby, it will return
NaN
> or raise an error, but never both.
>
> Guillaume.

Yeah, I wasn't thinking.  It would be kinda neat if we could (though I
have no idea how that would be implemented).

What about a compromise where an error is raised, and "NaN" is included
in part of the error message, e.g.

Errno::EDOM: NaN (sqrt)

Or something like that?

Dan

PS - I think this is my 4th attempted reply - if a bunch of similar
messages show up later, it's my mail server acting up.