From owner-sc22wg5@dkuug.dk Fri Aug 15 02:14:32 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h7F0EW6C075569 for sc22wg5-domo; Fri, 15 Aug 2003 02:14:32 +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 nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h7F0EMEc075563 for ; Fri, 15 Aug 2003 02:14:26 +0200 (CEST) (envelope-from corbett@mpkmail.eng.sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7F0EE5K012156; Thu, 14 Aug 2003 17:14:14 -0700 (PDT) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7F0EEV7021077; Thu, 14 Aug 2003 17:14:14 -0700 (PDT) Received: from lupa (lupa.Eng.Sun.COM [129.146.78.104]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with SMTP id <0HJM003FXWNQXJ@mpkmail.eng.sun.com>; Thu, 14 Aug 2003 17:14:14 -0700 (PDT) Date: Thu, 14 Aug 2003 17:14:14 -0700 (PDT) From: Robert Corbett Subject: Re: (SC22WG5.2938) clarification of technical intent in N1553 To: longb@cray.com Cc: sc22wg5@dkuug.dk Reply-to: Robert Corbett Message-id: <0HJM003FYWNQXJ@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.8 SunOS 5.8 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: Mqp6FqlsN0/yW1GVW8M51A== Sender: owner-sc22wg5@dkuug.dk Precedence: bulk > I should point out that while the IEEE folks ponder, there is actual > text in the C standard on how to print NaN's (sections 7.19.6.1 and > 7.24.2.1). The rules there provide for the following forms: > > NAN > -NAN > NAN(n-char-sequence) > -NAN(n-char-sequence) > > and also version of the above with "NAN" replaced by "nan". The content > of the n-char-sequence is implementation dependent. This is pretty > close to what we have. As a practical matter, I think it is more > valuable to users to be compatible with what C programs produce for > output/ expect for input, than to conform to a proposal about what > might be considered by 754r. Ah. I was under the impression the Fortran proposal did not allow signed NaNs. That is a major improvement. Sincerely, Bob Corbett