From owner-sc22wg5@open-std.org Mon Mar 14 16:50:52 2005 Return-Path: X-Original-To: sc22wg5-domo1 Delivered-To: sc22wg5-domo1@open-std.org Received: by open-std.org (Postfix, from userid 521) id 7F71CDD80; Mon, 14 Mar 2005 16:50:52 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from dkuug.dk (ptah.dkuug.dk [195.215.30.66]) by open-std.org (Postfix) with ESMTP id 8CD85DA33 for ; Mon, 14 Mar 2005 16:50:41 +0100 (CET) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id j2EFlawE049326 for ; Mon, 14 Mar 2005 16:47:42 +0100 (CET) (envelope-from Keith.Bierman@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2EFM3Rr011415 for ; Mon, 14 Mar 2005 08:22:03 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IDC00KTBLCQOM@edgemail1.Central.Sun.COM> for sc22wg5@dkuug.dk; Mon, 14 Mar 2005 08:22:03 -0700 (MST) Received: from [192.168.0.7] ([68.99.235.74]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IDC000LRLCQ8A@mail.sun.net> for sc22wg5@dkuug.dk; Mon, 14 Mar 2005 08:22:02 -0700 (MST) Date: Mon, 14 Mar 2005 07:22:02 -0800 From: Keith Bierman Subject: Future of sNans In-reply-to: To: Fortran 90 List , sc22wg5@dkuug.dk Message-id: <4235AC1A.1030508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) References: <200501312210.j0VMA2Qm016752@math.jpl.nasa.gov> X-Spam-Score: 0 () Sender: owner-sc22wg5@open-std.org Precedence: bulk From this month's DDJ, in the Letters section: *Binary Floating-Point Arithmetic* Dear /DDJ/, In the past 20 years or so, the IEEE-754 Standard has brought about substantial improvements in the portability and reliability of programs that use binary floating-point arithmetic. But a lot has changed in 20 years, and we've realized that there are a few things in the Standard that could have been done better. One of them is the Signaling NaN (sNaN). Signaling NaNs were intended to extend the Standard in ways we could not foresee at the time. The idea was that sNaNs, together with carefully implemented versions of the optional trapping feature, would allow a user to implement new features in an economical and portable way for debugging or arithmetic extensions. Unfortunately, since traps were optional and each manufacturer chose to implement them in a slightly different way, sNaNs were not provided with the support they needed to flourish. Making traps both mandatory and portable is not feasible. The only remaining feature about sNaNs that could be counted on from one implementation to the next is that when an sNaN is encountered, it sets the Invalid flag and turns into a Quiet NaN (qNaN). Using this feature to extend the Standard turns out to be cumbersome and perhaps almost as easy to implement with qNaNs alone. For example, there have been attempts to fill uninitialized data with qNaNs containing identifying information sufficient to track down attempts to consume uninitialized variables. Beyond that, we know of very little that has been done with sNaNs, and none of it is portable. Further, recent informal inquiries have turned up no current use of sNaNs. In an attempt to simplify the Standard, we are, therefore, considering making sNaNs no longer mandatory with a view to their ultimate elimination. But we are concerned that doing so would violate the precedent established in 1985. We suspect the constituency counting on this one portable feature of sNaNs just might be empty. If so, the precedent serves no one and the elimination of sNaNs would cause no harm and do much good. Therefore, to perform due diligence, we are asking the software community if there is any portable software out there that requires this one feature of sNaNs in order to function. We would also like to learn about nonportable software that requires sNaNs. If you are responsible for such software, please contact us at snans@nonabelian.com with a description of the purpose of the software and how it uses sNaNs to accomplish that purpose. Source code would help but is not necessary if the application is clear enough. We thank you for your help in settling this matter. Dan Zuras Chairman, IEEE-754R