Re: +-Inf and NaN

[Raymond Toy]

On Wed, Feb 28, 2024 at 7:38 AM Stavros Macrakis <macrakis@gmail.com> wrote:

On Wed, Feb 28, 2024 at 10:12 AM Raymond Toy <toy.raymond@gmail.com> wrote:

On Wed, Feb 28, 2024 at 5:44 AM Camm Maguire <camm@maguirefamily.org> wrote:

...
> I hope you will consider changing the default to trap on invalid
> operations so that instead of returning NaN, an error is signaled.  ...
>

This is good to hear, as I was of the opposite impression that most
users wanted NaNs to propagate freely.

Maybe you should take a poll or something.  It could be that I'm just a terrible numerical programmer.  But in my experience, it's fairly easy to produce an infinity somewhere which then gets subtracted from infinity that then becomes NaN which then poisons all further computations.

I disagree vehemently. The behavior of NaN is extremely useful. For example, it is nice that [1,2,3]/[2.0,0.0,2.0] returns [0.5,NaN,1.5] rather than just ERROR.

R found this kind of behavior so useful in statistical calculations (where "missing value" is a reasonable thing to calculate with) that they added it to all numeric types, not just floats.

I think we'll just have to agree to disagree.  In a previous life I used to do simulations for the physical layer for cellular systems.  These would often take many hours (or days) to run.  If I messed up and accidentally did 1/0 because I forgot to initialize something, then after hours or days, all of the printed results were basically NaN.  I could have saved hours or days if I got an ERROR at the point where I divided by 0.  IIRC this usually happened fairly early in the code, not at the end.  

I guess this experience has influenced my strong desire to get errors signaled as soon as possible.  But I don't turn on underflow traps.  Underflows for my simulations were generally harmless.  Or at least I don't remember underflows causing bad results.

        -s

--

Ray