... 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?
I'm just guessing now but it seems that you are in an area that
changes depending on which compiler you are using (how does it
compile the FP instructions, does it use SSE instructions, how is
it checking equality) and which exact processor are you on, does
it support IEEE754, does the compiler try to support IEEE754
exactly? I haven't seen much in the forums about FP behaviour in
e.g. dmd. E.g. how does it deal with the issues raised in
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf? The people who
know these things can found discussing them at
http://forum.dlang.org/thread/khbodtjtobahhpzma...@forum.dlang.org?page=3#post-l4rj5o:24292k:241:40digitalmars.com
:-).
It's generally held that checking FP numbers for exact equality
isn't practical and it's better to go for equality within a
certain tolerance - any reason why you're not happy with that :-)?
