Equality == comparisons with floating point numbers

[Joseph Rushton Wakeling]

On 07/12/13 12:08, Joseph Rushton Wakeling wrote:
> On 07/12/13 09:29, Abdulhaq wrote:
>> Some time ago in a test I had written (C++) apparently identical floating point
>> operations were returning different answers (in the 17th/18th sign fig), when
>> re-running the same code with the same data. The paper described how the result
>> could change if the numbers remained in the FPU (which had a few bits extra
>> precision over the normal register size) during the course of the calculation as
>> a opposed to being swapped in and out of the main registers. Depending on when
>> numbers could get flushed out of the FPU (task swapping I suppose) you would get
>> slightly different answers.
>>
>> Could this be a factor?
>
> Yes, I think you are right.  In fact monarch_dodra had already pointed me
> towards this, but I slightly missed the point as I assumed this was about real
> vs. double (for example) comparisons, rather than type vs. FPU cache.
>
> Interestingly, it appears to only hit 32-bit D.  There's a bug report related to
> this here:
> http://d.puremagic.com/issues/show_bug.cgi?id=8745
>
> Anyway, I think I now have a firm idea how to move forward

... I thought I did, but now I'm up against an interesting conundrum: while 
equality == comparison can fail here for 32-bit, isIdentical comparison can fail 
even for 64-bit, although only for the release-mode build.

What's particularly odd is that if before calling assert(isIdentical( ... )) I 
use writeln to print the value of isIdentical(...) to the screen, then it prints 
true, and the assertion passes.  If I don't have the print statement, then the 
assert fails.

I'm presuming that calling writefln to print the variable involves it being 
taken off the FPU?