From owner-sc22wg5@dkuug.dk Fri Aug 15 20:32:42 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h7FIWg0v080006 for sc22wg5-domo; Fri, 15 Aug 2003 20:32:42 +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 mail1.cray.com (mail1.cray.com [136.162.0.111]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h7FIWWEc080000 for ; Fri, 15 Aug 2003 20:32:37 +0200 (CEST) (envelope-from longb@cray.com) Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.9/8.12.9/gw-1.2) with ESMTP id h7FIWM4G011693; Fri, 15 Aug 2003 13:32:23 -0500 (CDT) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.9/8.12.6/hub-1.2) with ESMTP id h7FIWLqH013835; Fri, 15 Aug 2003 13:32:21 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-20-206 [172.31.20.206]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id NAA2636731; Fri, 15 Aug 2003 13:32:20 -0500 (CDT) Message-ID: <3F3D2905.5060700@cray.com> Date: Fri, 15 Aug 2003 13:40:05 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Corbett CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2938) clarification of technical intent in N1553 References: <0HJM003FYWNQXJ@mpkmail.eng.sun.com> In-Reply-To: <0HJM003FYWNQXJ@mpkmail.eng.sun.com> Content-Type: multipart/alternative; boundary="------------090805060108030401020902" X-Cray-VirusStatus: clean Sender: owner-sc22wg5@dkuug.dk Precedence: bulk This is a multi-part message in MIME format. --------------090805060108030401020902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Corbett wrote: >>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. > > The current proposal does not allow signs. Thus "pretty close" rather that "the same as". One could argue that things that are not numbers do not have signs. On the other hand, signed NaN input/output may be worth considering in the context of C interoperability. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120 --------------090805060108030401020902 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Robert Corbett wrote:

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.

The current proposal does not allow signs. Thus "pretty close" rather that "the same as". One could argue that things that are not numbers do not have signs. On the other hand, signed NaN input/output may be worth considering in the context of C interoperability.

Cheers,
Bill

-- 
Bill Long                                   longb@cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

--------------090805060108030401020902--