From owner-sc22wg5@dkuug.dk Thu Aug 14 16:53:51 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h7EErpJ3072609 for sc22wg5-domo; Thu, 14 Aug 2003 16:53:51 +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 mail22.messagelabs.com (mail22.messagelabs.com [193.109.255.115]) by dkuug.dk (8.12.8p1/8.9.2) with SMTP id h7EEriEc072604 for ; Thu, 14 Aug 2003 16:53:46 +0200 (CEST) (envelope-from malcolm@nag.co.uk) X-VirusChecked: Checked X-Env-Sender: malcolm@nag.co.uk X-Msg-Ref: server-17.tower-22.messagelabs.com!1060872817!314595 X-StarScan-Version: 5.0.7; banners=nag.co.uk,-,- Received: (qmail 13340 invoked from network); 14 Aug 2003 14:53:37 -0000 Received: from smtp-1.star.net.uk (212.125.75.70) by server-17.tower-22.messagelabs.com with SMTP; 14 Aug 2003 14:53:37 -0000 Received: (qmail 21439 invoked from network); 14 Aug 2003 14:53:37 -0000 Received: from nagmx1.nag.co.uk (HELO nag.co.uk) (62.231.145.242) by smtp-1.star.net.uk with SMTP; 14 Aug 2003 14:53:37 -0000 Received: from brackley.nag.co.uk (brackley.nag.co.uk [192.156.217.21]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id PAA27861 for ; Thu, 14 Aug 2003 15:53:30 +0100 (BST) Received: (from malcolm@localhost) by brackley.nag.co.uk (8.11.1/8.11.1) id h7EEsl613622 for sc22wg5@dkuug.dk; Thu, 14 Aug 2003 15:54:47 +0100 (BST) (envelope-from malcolm) From: Malcolm Cohen Message-Id: <200308141454.h7EEsl613622@brackley.nag.co.uk> Subject: Re: (SC22WG5.2930) clarification of technical intent in N1553 To: sc22wg5@dkuug.dk Date: Thu, 14 Aug 2003 15:54:46 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Robert Corbett wrote: > Does it not bother the Fortran committees that they are > approving a different syntax for reading and writing > formatted NaN values from the syntax proposed by the > IEEE floating-point committee? No, because there is no such syntax. At the time of the last meeting, the proposal for formatting NaN values in strings had the status of "not discussed by the IEEE committee", i.e. someone had sent it in but it had not even been discussed, let alone decided upon. As Aleksandar noted, in any case we cannot wait for the 754r committee to finish. I'll further note that the 754r committee is seriously considering (to the extent that it was a declared intention!) NOT to be upwardly compatible with 754. Whether the extent of the differences will be easily papered over by software alterations, or whether this means new hardware, is unclear. >I am not certain you have not, since I have not seen the latest >version of your proposed syntax. However, based on the e-mail >I have seen, it does not appear you have. Actually, some of us had seen it. > The IEEE proposal uses >the sequence "sNaN" to indicate a signaling NaN. It used an >optional `+' and a mandatory `-' to indicate the sign of the NaN. IMO such characteristics are completely broken (not to mention internally contradictory - both 754 and all drafts of 754r say that they do NOT interpret the signs of NaNs!). And certainly 754 has licence for signalling NaNs to become nonsignalling at the drop of a hat (even on a "copy" operation), so making that characteristic the most important one (by putting it first) would be inappropriate. >I don't think either of those parts of the IEEE proposal are >part of the syntax the draft Fortran standard is using. Absolutely! >I posted a copy of the text of the IEEE proposal for reading and >writing NaNs to this mailing list when the subject first arose. >AFAICT, my posting was ignored. In any case, you can find the >proposal at http://754r.ucbtest.org. It is the proposal >"Conversion between binary floating-point and decimal character >strings." The part about reading and writing NaNs is on pages >8 and 9. Right, and first we notice that this is indeed merely a proposal that is being made *to* the 754r committee, it is not part of their current draft. Indeed the NaN part is merely a removable appendage of the "correctly rounded base conversion" proposal. And their current draft (coming out of their August 2003 meeting) still states: "NaNs encoded in decimal strings are not specified in this standard." Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk) ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________