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=unavailable autolearn_force=no version=3.4.4 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.stack.nl!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: How to check a Float for NaN Date: Tue, 27 May 2014 17:35:48 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3132e38d-18bb-4890-9cec-31056ac6e3ba@x19g2000prg.googlegroups.com> <83ce619a-beef-447f-91ef-ff3dd68ff9df@googlegroups.com> <3tso4mcv80hk.8j7e1grtnha0$.dlg@40tude.net> <6c8f74c9-4b4e-47a0-90e0-efa1ecdd5e2e@googlegroups.com> <840855a9-bda8-44b7-ab53-e157b4fc1d31@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1401230150 16664 69.95.181.76 (27 May 2014 22:35:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 27 May 2014 22:35:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:20081 Date: 2014-05-27T17:35:48-05:00 List-Id: "Adam Beneschan" wrote in message news:840855a9-bda8-44b7-ab53-e157b4fc1d31@googlegroups.com... On Tuesday, May 27, 2014 5:35:26 AM UTC-7, Maurizio Tomasi wrote: >> > That is, I see no sensible reason for NaNs or infinities -- they're >> > just ways of deferring detection of bugs. I would have hoped that Ada's >> > moved beyond that, just like it has for integers.] >> >> >> >> Being a scientist working with large chunks of data, I find NaNs useful >> in a number of situations. >> I work in a domain (observational cosmology) where we need to deal with >> sky maps containing >> ~10^7 pixels (you can think of a "map" as a 1D vector where pixels on the >> sky sphere are >> ordered according to some rule). Not every sky direction can be sampled, >> because of a number >> of problems (in the instrument, in the observational strategy, in the >> data reduction pipeline, etc.) >> >> Therefore, in my Python+NumPy codes I always mark such directions using >> "quiet NaNs". >> If I have to combine two maps in order e.g. to take their average, the >> usual rules for >> combining NaNs are be exactly what I want. Writing in Ada what I actually >> write in Python: >> >> for I := 1 to N do >> Average_Map(I) := 0.5 * (Map1(I) + Map2(I)); >> end loop; > >Well, that's actually half Pascal and half Ada, but we understand what you >mean. > >But you don't need NaN's built into the language in order to get that sort >of functionality. In >Ada (or C++ or any other language that supports operator overloading), it's >simple enough >to define an "optional floating-point" record type consisting of a float >and a Boolean, where >the Boolean indicates "missing data", and define operators that produce >"missing data" if >either operand is missing. So you could still write mostly the same code, >except that >converting to or from a float, or from a floating-point literal, takes a >little extra code. If one has function "+" (Right : Float) return Optional_Float; then the "extra code" is just preceeding the float value with a "+". Hardly earth-shaking. (And the usual complaint about using "+" as a conversion operator is a non-problem here as these are numeric types). I much prefer this sort of solution (where the missing values are explicitly treated) rather than using some sort of magic number (a NaN being an extreme version of that). The name alone tells you that it doesn't belong in a numeric type -- since when is something that is "not a number" belong in a type defining numbers? As usual, this is mainly a case of premature optimization (preverting the hardware to handle something that's a rare need -- I wonder how much faster float hardware could be if it didn't have to mess with NaNs? I know that they impacted our software floating point quite a bit even though I made no attempt to actually do anything useful with them.) Randy.