Always false float comparisons

[Tobias M via Digitalmars-d]

On Saturday, 21 May 2016 at 21:56:02 UTC, Walter Bright wrote:
> On 5/21/2016 11:36 AM, Tobias M wrote:
>> Sorry but this is a misrepresentation. I never claimed that 
>> the x87 doesn't
>> conform to the IEEE standard.
>
> My point was directed to more than just you. Sorry I didn't 
> make that clear.
>
>
>> The point is, that is IS possible to provide fairly reasonable 
>> and consistent
>> semantics within the existing standards (C, C++, IEEE, ...).
>
> That implies what I propose, which is what many C/C++ compilers 
> do, is unreasonable, inconsistent, not Standard compliant, and 
> not IEEE. I.e. that the x87 is not conformant :-)

I'm trying to understand what you want to say here, but I just 
don't get it. Can you maybe formulate it differently?

> Read the documentation on the FP switches for VC++, g++, clang, 
> etc. You'll see there are tradeoffs. There is no "obvious, 
> sane" way to do it.
>
> There just isn't.

As I see it, the only real trade off is speed/optimization vs 
correctness.

>> They provide a
>> certain degree of freedom to accomodate for different 
>> hardware, but this doesn't
>> mean that software should use this freedom to do arbitrary 
>> things.
>
> Nobody is suggesting doing arbitrary things, but to write 
> portable fp, take into account what the Standard says rather 
> than what your version of the compiler does with various 
> default and semi-documented switches.

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

Seems relatively straight forward to me and well documented to 
me...
Dangerous optimizations like reordering expressions are all 
opt-in.

Sure it's probably not 100% consistent across 
implementations/platforms, but it's also *that* bad. And it's 
certainly not an excuse to make it even worse.

And yes, I think that in such an underspecified domain like FP, 
you cannot just rely on the standard but have to take the 
individual implementations into account.
Again, this is not ideal, but let's not make it even worse.

>> Regarding the decades of FP design, the initial edition of K&R 
>> C contained the
>> following clause:
>> "Notice that all floats in an expression are converted to 
>> double; all floating
>> point arithmethic in C is done in double precision".
>> That passus was removed quite quickly because users complained 
>> about it.
>
> It was changed to allow floats to be computed as floats, not 
> require it. And the reason at the time, as I recall, was to get 
> faster floating point ops, not because anyone desired reduced 
> precision.

I don't think that anyone has argued that lower precision is 
better. But a compiler should just do what it is told, not trying 
to be too clever.