From owner-sc22wg5@dkuug.dk Fri Aug 15 00:28:37 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h7EMSb2f074847 for sc22wg5-domo; Fri, 15 Aug 2003 00:28:37 +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 h7EMSSEc074841 for ; Fri, 15 Aug 2003 00:28:32 +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 h7EMSK4G024813; Thu, 14 Aug 2003 17:28:21 -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 h7EMSJBa022303; Thu, 14 Aug 2003 17:28:19 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-16-138 [172.31.16.138]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id RAA2627068; Thu, 14 Aug 2003 17:28:19 -0500 (CDT) Message-ID: <3F3C0ED3.4070605@cray.com> Date: Thu, 14 Aug 2003 17:36:03 -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: Richard Maine CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2937) clarification of technical intent in N1553 References: <200308141453.h7EErqak072620@dkuug.dk> <200308142147.h7ELlFGo074721@dkuug.dk> In-Reply-To: <200308142147.h7ELlFGo074721@dkuug.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean 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. Cheers, Bill Richard Maine wrote: >Malcolm Cohen writes: > > > this is indeed merely a proposal that is > > being made *to* the 754r committee, > >This suggests that I could write a paper proposing that NaNs >be output as the string "Like, this is strange, dude." and >it would have just as much standing. > >You could certainly draw some pretty strange and inconsistent >conclusions if you took every paper that appears in a J3 or WG5 >distribution as a proposal by J3/WG5. I've seen people do things like >that and had to point out the distinction. > > > -- 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