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?
