Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/16/2016 7:37 AM, H. S. Teoh via Digitalmars-d wrote:
> An algorithm that uses 80-bit but isn't written properly to account for
> FP total precision loss will also produce wrong results, just like an
> algorithm that uses 64-bit and isn't written to account for FP total
> precision loss.

That is correct. But in most routine cases, it's enough more precision that 
going to more heroic algorithm changes become unnecessary.


> If I were presented with product A having an archaic feature X that
> works slowly and that I don't even need in the first place, vs. product
> B having exactly the feature set I need without the baggage of archaic
> feature X, I'd go with product B.

I have business experience with what people actually choose, and it's often not 
what they say they would choose. Sorry :-)

Social proof (i.e. what your colleagues use) is a very, very important factor. 
But having a needed feature not available in the more popular product trumps 
social proof. It doesn't need to appeal to everyone, but it can be the wedge 
that drives a product into the mainstream.

The needs of numerical analysts have often been neglected by the C/C++ 
community. The community has been very slow to recognize IEEE, by about a 
decade. It wasn't until fairly recently that C/C++ compilers even handled NaN 
properly. It's no surprise that FORTRAN reigned as the choice of numerical analysts.

(On the other hand, the needs of game developers have received strong support.)

The dismissal of concerns about precision as "archaic" is something I have seen 
for a long time.

As my calculator anecdote illustrates, even engineers do not recognize loss of 
precision when it happens. I'm not talking about a few bits in last place, I'm 
talking about not recognizing total loss of precision.

I sometimes wonder how many utter garbage FP results are being generated and 
treated as correct answers by researchers who confuse textbook math with FP 
math. The only field I can think of where a sprinkling of garbage results don't 
matter as long as it is fast is game programming.

Even if you select doubles for speed, it's nice to be able to temporarily swap 
in reals as a check to see if the similar results are computed. If not, you 
surely have a loss of precision problem.