Always false float comparisons

Manu via Digitalmars-d digitalmars-d at puremagic.com
Sun May 15 22:13:34 PDT 2016


On 16 May 2016 at 14:26, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/15/2016 9:02 PM, Manu via Digitalmars-d wrote:
>>
>> If that code were to CTFE, I expect the CTFE to use extended precision.
>> My point is, CTFE should surely follow the types and language
>> semantics as if it were runtime generated code... It's not reasonable
>> that CTFE has higher precision applied than the same code at runtime.
>> CTFE must give the exact same result as runtime execution of the function.
>
>
> It hasn't for decades on x86 machines, and the world hasn't collapsed, in
> fact, few people ever even notice. Not many people prefer less accurate
> answers.

That doesn't mean it's not wrong.
Don noticed, he gave a lecture on floating-point gotchas.
I'm still firmly engaged in trying to use D professionally... should I
ever successfully pass that barrier, then it's just a matter of time
until such a piece of code that tend to challenge these things is
written. There are not enough uses of D that we can offer anecdotes,
but we can offer anecdotes from our decades with C++ that we would
desperately like to avoid in the future.

If we don't care about doing what's right, then we just accept that
float remains a highly expert/special-knowledge-centric field, and
talks like the one Don gave should be taken as thought-provoking,
however of no practical relevance for the language, since it's 'fine
for most people, most of the time', and we get on with other things.
This thread is evidence that people would like to do the best we can.

1.3f != 1.3 is not accurate, it's wrong.


> The initial Java spec worked as you desired, and they were pretty much
> forced to back off of it.

Ok, why's that?


>>> The belief that compile time and runtime are exactly the same floating
>>> point
>>> in C/C++ is false.
>>
>>
>> I'm not interested in C/C++, I gave some anecdotes where it's gone
>> wrong for me too, but regardless; generally, they do match, and I
>> can't think of a single modern example where that's not true. If you
>> *select* fast-math, then you may generate code that doesn't match, but
>> that's a deliberate selection.
>
>
> They won't match on any code that uses the x87. The standard doesn't require
> float math to use float instructions, they can (and do) use double
> instructions for temporaries.

If it does, then it is careful to make sure the precision expectations
are maintained. If you don't '-ffast-math', the FPU code produces a
IEEE conformant result on reasonable compilers. We depend on this.


>> If I want 'real' math (in CTFE or otherwise), I will type "real". It
>> is completely unreasonable to reinterpret the type that the user
>> specified. CTFE should execute code the same way runtime would execute
>> the code (without -ffast-math, and conformant ieee hardware). This is
>> not a big ask.
>>
>> Incidentally, I made the mistake of mentioning this thread (due to my
>> astonishment that CTFE ignores float types)
>
>
> Float types are not selected because they are less accurate, they are
> selected because they are smaller and faster.

They are selected because they are smaller and faster with the
understood trade-off that they are less accurate.
They are certainly selected with the _intent_ that they are less accurate.

It's not reasonable that a CTFE function may produce a radically
different result than the same function at runtime.

>> out loud to my
>> colleagues... and they actually started yelling violently out loud.
>> One of them has now been on a 10 minute angry rant with elevated tone
>> and waving his arms around about how he's been shafted by this sort
>> behaviour so many times before. I wish I recorded it, I'd love to have
>> submit it as evidence.
>
>
> I'm interested to hear how he was "shafted" by this. This apparently also
> contradicts the claim that other languages do as you ask.

I've explained prior the cases where this has happened are most often
invoked by the hardware having a reduced runtime precision than the
compiler. The only cases I know of where this has happened due to the
compiler internally is CodeWarrior; an old/dead C++ compiler that
always sucked and caused us headaches of all kinds.
The point is, the CTFE behaviour is essentially identical to our
classic case where the hardware runs a different precision than the
compiler, and that's built into the language! It's not just an anomaly
expressed by one particular awkward platform we're required to
support.


More information about the Digitalmars-d mailing list