Arithmetic error when comparing NaN

Bug #1712697 reported by Christophe on 2017-08-23
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Undecided
Unassigned

Bug Description

1. Not sure if this is intended or not, but comparing two (quiet) NaN using "=" throws floating-point-invalid-operation; I would expect the result to be NIL, based on IEEE-754.

2. (= (sb-kernel:make-single-float #x7FFFFFFF)
      (sb-kernel:make-single-float #x7FFFFFFF))

; Evaluation aborted on #<FLOATING-POINT-INVALID-OPERATION {1006900C03}>.

3. sbcl --version
   SBCL 1.3.13.7.master.75-b464cda

4. *FEATURES*

(:EOS ALEXANDRIA.0.DEV::SEQUENCE-EMPTYP :SWANK :QUICKLISP
 :SB-BSD-SOCKETS-ADDRINFO :ASDF-PACKAGE-SYSTEM :ASDF3.1 :ASDF3 :ASDF2 :ASDF
 :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :64-BIT :64-BIT-REGISTERS
 :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :C-STACK-IS-CONTROL-STACK
 :COMMON-LISP :COMPACT-INSTANCE-HEADER :COMPARE-AND-SWAP-VOPS
 :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS
 :FP-AND-PC-STANDARD-SAVE :GENCGC :IEEE-FLOATING-POINT :IMMOBILE-CODE
 :IMMOBILE-SPACE :INLINE-CONSTANTS :INTEGER-EQL-VOP :LARGEFILE :LINKAGE-TABLE
 :LINUX :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS
 :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN
 :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC
 :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR
 :RAW-INSTANCE-INIT-VOPS :RAW-SIGNED-WORD :SB-AFTER-XC-CORE
 :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS
 :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-UNICODE
 :SB-XREF-FOR-INTERNALS :SBCL :STACK-ALLOCATABLE-CLOSURES
 :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS
 :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS
 :UNBIND-N-VOP :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)

-----

I am in a Yak shaving process: I was using the IEEE-FLOATS library and noticed that SBCL defines custom floating-point operations in SB-EXT; I generated a NaN with MAKE-SINGLE-FLOAT and wanted to see what Slime's fancy inspector would do with that value. An exception occurred instead, which leads me to send a pull request (see commit https://github.com/slime/slime/commit/925dd2d85e6f0aadee78c9c08b51991bad8b12ca).

Now, I am wondering if this is really necessary: shouldn't TWO-ARG-= simply returns NIL when given at least one NaN?

description: updated
description: updated
Christophe (junke-christophe) wrote :

Ok, the current behavior is probably fine because it is better to signal the caller that we are operating on NaN values than to silently return NIL. It is also fine with IEEE-754 which defines FP exceptions.

Changed in sbcl:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers