From owner-sc22wg5@dkuug.dk Fri Aug 8 17:07:15 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h78F7F4R030916 for sc22wg5-domo; Fri, 8 Aug 2003 17:07:15 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h78F5gEc030900 for ; Fri, 8 Aug 2003 17:07:10 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for sc22wg5@dkuug.dk; Fri, 8 Aug 2003 08:02:40 -0700 Received: from altair.dfrc.nasa.gov ([130.134.20.211]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Fri, 8 Aug 2003 08:05:35 -0700 Received: by altair.dfrc.nasa.gov (Postfix, from userid 201) id 212FA357ED; Fri, 8 Aug 2003 08:05:32 -0700 (PDT) From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16179.48187.871844.848245@altair.dfrc.nasa.gov> Date: Fri, 8 Aug 2003 08:05:31 -0700 To: sc22wg5@dkuug.dk Subject: (SC22WG5.2924) clarification of technical intent in N1553 In-Reply-To: <200308081330.h78DUv8x030439@dkuug.dk> References: <200308072303.h77N34rh026353@dkuug.dk> <200308081249.h78CnM0a030247@dkuug.dk> <200308081330.h78DUv8x030439@dkuug.dk> X-Mailer: VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk John Reid writes: > Yes, I agree. The subgroup overlooked the fact that the edit addressed > point 4. That was my guess, but I wasn't 100% sure. > I suggest the following edit: > > [230:32] After the "." Insert > "If the NaN is a signaling NaN, the string 'NaN' shall be followed > by characters enclosed in parentheses." Hmm. That raises another point of non-symmetry - one which I had failed to note before. Again, I'm not sure whether it is intentional or not. My suspicion is that it is unintentional, but I find it at least concievable that there is technical reason for it (perhaps relating to processor support for signalling vs quite NaNs). My proposed edit talked about what happens for quiet NaNs, because that is how input was specified. For input, we specify that if there are no characters after the "NaN", we get a quiet NaN. I'm a bit suspicious that someone thought this conversely requires that if there are characters after the "NaN", we get a signaling NaN, but that implication is incorrect. (As workers on a mathematically oriented language, we ought to know that a statement does not imply its converse). Does anyone know whether we assumed the converse or whether we meant exactly what we said? I'm guessing that we also intended the converse, but I'm not 100% sure of that guess. Anyway, if we really meant exactly what we said for input (specifying that we get a quiet NaN when there are no optional characters, but allowing the form with optional characters to give either a quiet or signalling NaN), then the above edit for output isn't symmetric. Exact edits I (well, J3) can work; this particular stuff isn't difficult. I'm just trying to clarify technical intent. To me th etechnical intent isn't yet quite clear. -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain