Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/15/2016 10:24 PM, Manu via Digitalmars-d wrote:
> On 16 May 2016 at 14:31, Walter Bright via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 5/15/2016 9:05 PM, Manu via Digitalmars-d wrote:
>>>
>>> I've never read the C++ standard, but I have more experience with a
>>> wide range of real-world compilers than most, and it is rarely very
>>> violated.
>>
>>
>> It has on every C/C++ compiler for x86 machines that used the x87, which was
>> true until SIMD, and is still true for x86 CPUs that don't target SIMD.
>
> It has what? Reinterpreted your constant-folding to execute in 80bits
> internally for years? Again, if that's true, I expect that's only true
> in the context that the compiler also takes care to maintain the IEEE
> conformant bit pattern, or at very least, it works because the
> opportunity for FP constant folding in C++ is almost non-existent
> compared to CTFE, such that it's never resulted in a problem case in
> my experience.

Check out my other message to you quoting the VC++ manual. It does constant 
folding at higher precision. So does gcc:

http://stackoverflow.com/questions/7295861/enabling-strict-floating-point-mode-in-gcc


> In D, we will (do) use CTFE for table generation all the time (this
> has never been done in C++). If those tables were generated with
> entirely different precision than the runtime functions, that's just
> begging for trouble.

You can generate the tables at runtime at program startup by using a 'static 
this()' constructor.


> In the majority of my anecdotes, if they don't match, there are
> cracks/seams in the world. That is a show-stopping bug. We have had
> many late nights, even product launch delays due to by these problems.
> They have been a nightmare to solve in the past.
> Obviously the solution in this case is a relatively simple
> work-around; don't use CTFE (ie, lean on the LLVM runtime codegen
> instead to do the right thing with the float precision), but that's a
> tragic solution to a problem that should never happen in the first
> place.

You're always going to have tragic problems if you expect FP to behave like 
conventional mathematics. Just look at all the switches VC++ has that influence 
FP behavior. Do you really understand all that?

Tell me you understand all the gcc floating point switches?

https://gcc.gnu.org/wiki/FloatingPointMath

How about g++ getting different results based on optimization switches?

http://stackoverflow.com/questions/7517588/different-floating-point-result-with-optimization-enabled-compiler-bug

-------

Or, you could design the code so that there aren't cracks because it is more 
tolerant of slight differences, i.e. look for so many mantissa bits matching 
instead of all of them matching. This can be done by subtracting the operands 
and looking at the magnitude of the difference.

The fact that you have had "many late nights" and were not using D means that 
the compiler switches you were using were not adequate or were not doing what 
you thought they were doing.