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.50.225.4 with SMTP id rg4mr12554196igc.1.1401194127230; Tue, 27 May 2014 05:35:27 -0700 (PDT) X-Received: by 10.140.92.82 with SMTP id a76mr520190qge.1.1401194127129; Tue, 27 May 2014 05:35:27 -0700 (PDT) Path: border1.nntp.dca.giganews.com!nntp.giganews.com!c1no18226441igq.0!news-out.google.com!qf4ni13600igc.0!nntp.google.com!c1no18226431igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 27 May 2014 05:35:26 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=159.149.44.166; posting-account=uPViEgkAAACC04vaTYL5Kyk76brV1MA_ NNTP-Posting-Host: 159.149.44.166 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: How to check a Float for NaN From: Maurizio Tomasi Injection-Date: Tue, 27 May 2014 12:35:27 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:186649 Date: 2014-05-27T05:35:26-07:00 List-Id: > 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 be= yond 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 re= duction pipeline, etc.) Therefore, in my Python+NumPy codes I always mark such directions using "qu= iet NaNs". If I have to combine two maps in order e.g. to take their averag= e, the usual rules for combining NaNs are be exactly what I want. Writing i= n Ada what I actually write in Python: for I :=3D 1 to N do Average_Map(I) :=3D 0.5 * (Map1(I) + Map2(I)); end loop; If either Map1(I) or Map2(I) (or both) are NaN, then Average_Map(I) will be= a NaN too, which is correct from the point of view of the meaning of the m= easurement. But without proper treatment of NaNs, one should write for I in Map1'Range do if not Is_NaN(Map1(I)) and not Is_NaN(Map2(I)) then Average_Map(I) :=3D 0.5 * (Map1(I) + Map2(I)); else Set_To_NaN(Average_Map, I); end if; end loop; If one has to run many calculations on such maps (which is indeed always th= e case) instead of just a plain average, the code can get quite complex. An= d I do not think one gets more safety from such verbosity, as what a scient= ist expects from a NaN number is actually what the usual rules for NaN give= . I am not an Ada export, so these are just my two cents, Maurizio.