From: Taylor R Campbell <campbell@mumble.net>
Date: Thu, 3 Oct 2019 16:23:03 +0000 (+0000)
Subject: A reader has alerted me to a caveat about IEEE 754 min/max.
X-Git-Tag: mit-scheme-pucked-10.1.20~11^2~38
X-Git-Url: https://birchwood-abbey.net/git?a=commitdiff_plain;h=d6e79ed1b065b446b928aa84452ff36d85927663;p=mit-scheme.git

A reader has alerted me to a caveat about IEEE 754 min/max.
---

diff --git a/src/relnotes/bug-minmax b/src/relnotes/bug-minmax
index d1b14debb..844317437 100644
--- a/src/relnotes/bug-minmax
+++ b/src/relnotes/bug-minmax
@@ -3,5 +3,11 @@ as minNum/maxNum.
 
 When one input is a quiet NaN, they return the other input.  Only when
 both inputs are NaN or one input is a signalling NaN do they return a
-NaN, and in either case, it is a quiet NaN.  These trap only when the
-floating-point invalid-operation exception is trapped.
+NaN, and in either case, it is a quiet NaN[*].  These trap only when
+the floating-point invalid-operation exception is trapped.
+
+[*] Caveat: The IEEE 754 committee is considering changing the
+behaviour of these operations on signalling NaN, because the current
+semantics is nonassociative: min(1, min(2, sNaN)) = 1, whereas
+min(min(1, 2), sNaN) = qNaN.  So don't go around relying on this
+semantics for sNaN inputs too heavily!