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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.12.14 with SMTP id v14mr6251984qav.8.1400772514170; Thu, 22 May 2014 08:28:34 -0700 (PDT) X-Received: by 10.50.43.164 with SMTP id x4mr492233igl.6.1400772514075; Thu, 22 May 2014 08:28:34 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!c1no13713213igq.0!news-out.google.com!qf4ni5721igc.0!nntp.google.com!c1no13713193igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 22 May 2014 08:28:33 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: <3132e38d-18bb-4890-9cec-31056ac6e3ba@x19g2000prg.googlegroups.com> <83ce619a-beef-447f-91ef-ff3dd68ff9df@googlegroups.com> <3tso4mcv80hk.8j7e1grtnha0$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6c8f74c9-4b4e-47a0-90e0-efa1ecdd5e2e@googlegroups.com> Subject: Re: How to check a Float for NaN From: Adam Beneschan Injection-Date: Thu, 22 May 2014 15:28:34 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:19973 Date: 2014-05-22T08:28:33-07:00 List-Id: On Thursday, May 22, 2014 2:48:47 AM UTC-7, Dmitry A. Kazakov wrote: > On Thu, 22 May 2014 10:24:35 +0100, Simon Wright wrote: >=20 > > "Dmitry A. Kazakov" writes: >=20 > >> On Thu, 22 May 2014 00:27:02 -0700 (PDT), jan.de.kruyf wrote: > >>> if Cos_Theta /=3D Cos_Theta then >=20 > >>> Gct.Trace (Debug_Str, "cos_theta is NaN******"); >=20 > >>> else >=20 > >>> Gct.Trace (Debug_Str, "cos_theta : " & Long_Float'Image (Cos_Theta)= );=20 >=20 > >>> end if; >=20 > >>>=20 >=20 > >>> gives this in the log: >=20 > >>>=20 >=20 > >>> [MATH3D.DEBUG] 1/372 cos_theta is NaN****** (2014-05-22 09:23:24.155)= (loc: math3d.adb:129) >=20 > >>>=20 >=20 > >>> Hope it helps someone; >=20 > >> >=20 > >> You could simply use range check: > >> X in Long_Float'Range > >> NaN is not a number and thus outside the range. > > This would also return False for +/-Inf, so if the OP wants specificall= y > > to check for NaN it wouldn't do. Can't think why they would, though. > > GNAT says about "X in Long_Float'Range" >=20 > > inf.adb:10:60: warning: explicit membership test may be optimized aw= ay > Looks like a bug, it may not be optimized away if Long_Float is IEEE 754. > > inf.adb:10:60: warning: use 'Valid attribute instead =20 > Hmm, reading RM 13.9.2 makes me believe that NaN's 'Valid should yield > True. No, I don't think so. 3.5.7(8) says "The set of values for a floating poin= t type is the (infinite) set of rational numbers." This excludes NaN and i= nfinities, which are not rational numbers (nor any kind of number). Theref= ore, if X contains an infinity or NaN, X'Valid should be false. Unlike some languages (e.g. Java), Ada doesn't define +/- Infinity or NaN t= o be valid values in the language, and therefore it can't make any statemen= ts about how they're supposed to be handled. Normally, an operation that r= esults in infinity or NaN is supposed to raise Constraint_Error. However, = the language allows for implementations not to check this, by providing a M= achine_Overflows attribute that is False if Constraint_Error isn't raised. = As far as I can tell, however, the language doesn't say anything about wha= t happens otherwise, except that the result is "unspecified" or "implementa= tion-defined". Even where an implementation is required to support IEEE 75= 4 semantics (I think this is required if an implementation claims to suppor= t Annex G), I don't believe the requirements apply to NaN or Infinity even = if Machine_Overflows is False--since those aren't really valid values in th= e language, I don't think the language can impose any requirements on how t= hey're handled. In particular, that means that a condition like if Cos_Theta /=3D Cos_Theta then ... could be treated the same as if False then ... by the compiler. And yes, "X in Long_Float'Range" could be treated as "kno= wn to be True". Maybe it will and maybe it won't, but the thing is, you ca= n't count on it in Ada. You may be able to count on it for a specific comp= iler, depending on what the compiler vendor promises. But it won't be port= able. (The warning could be a GNAT bug within the context of what GNAT's d= ocumentation says the compiler should do--I don't know, I haven't read all = of it--but this behavior is permissible in Ada.) There are a few statements in the AARM that say "It is anticipated that an = Ada binding to IEC 559:1989 will be developed in the future" or something s= imilar, and those sections do discuss treating infinities and NaN's as valu= es and anticipate that there will be language rules about how they're to be= handled. However, I notice that those statements were in the Ada 95 AARM = and haven't really been changed since. On Google Groups, this thread inclu= des some posts going back to 2008 about this subject, including one by Rand= y about why the ARG hasn't addressed this yet. -- Adam