Re: Converting NaN to integer 0.

Re: Converting NaN to integer 0.

[Richard Stallman]

Does anyone know what is the "correct" thing to do in this case
according to IEEE?  Would returning NaN be correct?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Converting NaN to integer 0.

[Luc Teirlinck]

Richard Stallman wrote:

   Does anyone know what is the "correct" thing to do in this case
   according to IEEE?  Would returning NaN be correct?

The functiona ffloor, fceiling, ftruncate and fround all return (I
believe correctly) NaN when passed NaN.  They also return +INF or -INF
when passed those values.

The trouble with floor, ceiling, truncate and round seems to be that
these functions are supposed to return an integer, and NaN and the
infinities are floats, not integers.  So the problem is not what the
rounded value of NaN should be, that would clearly seem to be NaN, but
whether it makes sense to cast NaN to an integer.

I do not know what the IEEE floating point standard says about casting
these values to integers.  It is not guaranteed to say anything about
it, since it is a floating point standard.

The rounding functions in the GNU C library that return a floating
point number all behave like ffloor et al.  The rounding
functions that return integers (lrint and lround) seem to return
nonsense values when fed NAN or infinities.  So does trying to cast
NAN or an infinity to int.

floor, ceiling, truncate and round all produce an error when passed
infinity, I guess because the logical rounded value returned by ffloor
et al is not an integer.  Unless the IEEE standard says something
else, it would seem consistent to give an error message when NaN is
passed since the logical rounded value (NaN) returned by ffloor et al
is not an integer either.

It seems like somebody who expects NaN to be rounded to Nan would call
ffloor or similar, because he would not be insisting on an integer
result.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Converting NaN to integer 0.

[Paul Eggert]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 12 Feb 2002 08:24:43 -0700 (MST)
> 
> Does anyone know what is the "correct" thing to do in this case
> according to IEEE?

ANSI/IEEE Std 754-1985 section 7.1 says:

  The invalid operation exception is signaled if an operand is invalid
  for the operation to be performed.  The result, when the exception
  occurs without a trap, shall be a quiet NaN (6.2) provided the
  destination has a floating-point format.  The invalid operations are
  ...

    (7) Conversion of a binary floating-point number to an integer or
    decimal format when overflow, infinity, or NaN precludes a
    faithful representation in that format and this cannot otherwise
    be signaled

> Would returning NaN be correct?

Yes, if you decide that the destination format is a Lisp object, since
a Lisp object can faithfully represent NaN.  Similarly, it would be
correct to return +-infinity for infinities and for floating-point
numbers that are too large to represent in the destination integer
format.

However, if you decide that the destination format must be an integer
Lisp object (i.e. that it cannot be a floating-point Lisp object),
then the ANSI/IEEE 754 is silent about what integer is returned for
NaNs, infinities, and out-of-range floating-point numbers.

The ISO C 99 standard agrees with ANSI/IEEE 754 here.  It says that on
a host that uses IEEE floating point, when a NaN or out-of-range value
is converted to an (necessarily fixed-width) integer, the invalid
operation exception is raised and the resulting integer value is
unspecified.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Converting NaN to integer 0.

[Luc Teirlinck]

Note that the value that the integer rounding functions return when
passed NaN seems to be very much machine dependent.  They returned 0
on the machine I used previously (mentioned in the return of the
emacs-version function).  This occurred both in Emacs20.7 and 21.1.90.
They return -1 in the setup below.  Eli Zaretskii reports that on his
machine, which supports infinities and NaN, they actually generate an
error.

** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (floor 0.0e+NaN)
-1
ELISP> (ceiling 0.0e+NaN)
-1
ELISP> (truncate 0.0e+NaN)
-1
ELISP> (round 0.0e+NaN)
-1
ELISP> (emacs-version)
"GNU Emacs 20.7.1 (sparc-sun-solaris2.8, X toolkit)\n of Thu Apr 12
2001 on eel\"


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel