O
I've looked around a little bit and teh interwebs say, "never test
floating point for equality", which is the way we are headed here.
Aside from NEON not being fully IEEE 754 compliant as Doug mentioned,
it looks like x86 (this statement not true for x86_64) has excess
precision inside the floating point registers so you may get different
results comparing a recently computed value with one loaded from
memory. I haven't found any suggestions for a threshold.
On a fun note, you can see there's a bazillion bug reports to GCC
based on this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
Nathan
I learned, back in the Pleistocene Era, never to test floating-point
values for exact equality. Anyone who is doing so is living in a state
of sin.
But my surprise was in learning that two modern-CPU floating-point
implementations, starting from the same starting conditions, would produce
slightly different answers, and the reason, is that not everybody
supports IEEE-754, or not, perhaps, all the rounding rules of IEEE-754,
while
perhaps supporting the format.
It's not like there's non-determinism going on. The same CPU will
always produce the same floating-point result, given the same starting
conditions, and the same chain of floating-point operations.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
