Always false float comparisons

[Ethan Watson via Digitalmars-d]

On Wednesday, 18 May 2016 at 06:57:58 UTC, Walter Bright wrote:
> I don't understand the 24 vs 32 bit value thing. There is no 32 
> bit mantissa floating point type. Floats have 24 bit mantissas, 
> doubles 52.

Not in the standards, no. But older gaming hardware was never 
known to be standards-conformant.

As it turns out, the original hardware manuals can be found on 
the internet.

https://www.dropbox.com/s/rsgx6xmpkf2zzz8/VU_Users_Manual.pdf

Relevant info copied from page 27:

Calculation
* A 24-bit calculation including hidden bits is performed, and 
the result is truncated.  The rounding-off operation in IEEE 754 
is performed in the 0 direction, so the values for the least 
significant bit may vary.

> In any case, the problem Manu was having was with C++.

VU code was all assembly, I don't believe there was a C/C++ 
compiler for it.

> My proposal would make the behavior more consistent than C++, 
> not less.

This is why I ask for a compiler option to make it consistent 
with the C++ floating point architecture I select. Making it 
better than C++ is great for use cases where you're not 
inter-opping with C++ extensively.

Although I do believe saying C++ is just clouding things here. 
Language doesn't matter, it's the runtime code using a different 
floating point instruction set/precision to compile time code 
that's the problem. See the SSE vs x87 comparisons posted in this 
thread for a concrete example. Same C++ code, different 
instruction sets and precisions.

Regardless. Making extra build steps with pre-calculated values 
or whatever is of course a workable solution, but it also raises 
the barrier of entry. You can't just, for example, select a 
compiler option in your IDE and have it just work. You have to go 
out of your way to make it work the way you want it to. And if 
there's one thing you can count on, it's end users being lazy.