From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,772ddcb41cd06d5b X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder3.cambrium.nl!feeder2.cambrium.nl!feed.tweaknews.nl!193.201.147.68.MISMATCH!feeder.news-service.com!news.albasani.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: How to check a Float for NaN Date: Wed, 30 Apr 2008 18:29:14 -0500 Organization: Jacob's private Usenet server Message-ID: References: <3132e38d-18bb-4890-9cec-31056ac6e3ba@x19g2000prg.googlegroups.com> <6f7cd771-16b7-4729-9536-2a7d1c28a9cd@2g2000hsn.googlegroups.com> <93b0d930-102a-4ac4-8b85-48e87d9d3df1@j33g2000pri.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1209598162 1116 69.95.181.76 (30 Apr 2008 23:29:22 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 30 Apr 2008 23:29:22 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:21155 Date: 2008-04-30T18:29:14-05:00 List-Id: "Adam Beneschan" wrote in message news:93b0d930-102a-4ac4-8b85-48e87d9d3df1@j33g2000pri.googlegroups.com... ... > P.S. Has the ARG or anyone discussed the possibility of building > support for infinities and/or NaN's into the language---i.e. defining > a floating-point type that includes those "values"? G.1.1(56) makes > me think that maybe there were some thoughts that this might be done > sometime in the future, if there's a demand for it, but I could be > reading something into this paragraph that isn't there. The "Rationale for Ada 2005" notes that AI95-00315 proposed such support: see http://www.adaic.com/standards/05rat/html/Rat-9-3-3.html. To expand a bit on the reasons for not including this: The proposal would have required vastly different (and much worse in general) code generation and optimization: much of what you can prove about values and expressions goes out the window when you include NaNs and infinitities in the equation. The proposal suggested a different mode for this, but some implementers did not want to have to really support separate modes (they treat the "relaxed" and "strict" modes the same). Moreover, the ARG didn't have any experts that could really tell us if the proposal was useful or overkill, and vendors didn't seem to have paying customers with specific concerns. As such, there was no consensus on how to proceed, and it was tabled to put our energies toward areas that we understood and had consensus for. I believe the ARG will revisit this area if we get the right expertise (and vendors have paying customers who care: I know RR does not have such customers today). Randy.