Re: How to check a Float for NaN

[Maurizio Tomasi <ziotom78@gmail.com>]

> 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;

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 measurement. 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) := 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 the case) instead of just a plain average, the code can get quite complex. And I do not think one gets more safety from such verbosity, as what a scientist 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.