Both C and C++.
> This is not unique to NaNs. There are plenty of potential floating point problems if you enable those flags.
That's why I said in the second part that we need to do away with them.
Seems C++ only added it in C++11. Surprising.
> That's why I said in the second part that we need to do away with them.
Do away entirely with fast math calculations? That would be horrible. They exist for a very good reason: Some applications are too slow without them. Enabling subnormal numbers can really slow things down.
I'd wager that for the majority of programs written, the fast math is as good as the accurate math.
I'd take that wager. I spent 13 years working on video games and video game technology, a domain where floating point performance is critical, and by and large we never used fast-math because of the problems it created for us.
I added it to Digital Mars C and C++ in the early 1990s. Also full NaN support in all the math.h functions. AFAIK it was the first C compiler to do it.
It was based on a specification worked out by NCEG (Numerical C Extensions Group), a long forgotten group that tried to modernize C numerics support.
> the fast math is as good as the accurate math
I was more interested in correct results than fast wrong answers.
I fully expect the intersection between programs where floating point instructions are a speed bottleneck and programs where the numerical instability that fast_math can cause is not a problem is the empty set.
Most programs don't care about the difference between ((a+b)+c) vs (a+(b+c)). Why bother with NaNs if you know you can't get them? Etc.
