Ahah, Apple does have different math
nntp.perl.org
Ahah, Apple does have different math
1–10 of 37 posts
Re: Ahah, Apple does have different math
#2It has been long known that one cannot rely on floating point for precise calculations, e.g. monetary values. One should use integers instead or some kind of other precise representation. But it does surprise me that even on the same CPU architecture you cannot expect every machine to produce the same results.
Re: Ahah, Apple does have different math
#3Tell PG: When I submitted this article, HN stripped the "!" characters out of the title...but I was then able to edit the story and put them back in there. I suppose that means there's a small bug in there somewhere...
Re: Ahah, Apple does have different math
#4Wasn't a very similar phenomenon a huge blow to Intel's PR some years back?
Re: Ahah, Apple does have different math
#5It has been long known that one cannot rely on floating point for precise calculations, e.g. monetary values. One should use integers instead or some kind of other precise representation. But it does surprise me that even on the same CPU architecture you cannot expect every machine to produce the same results.
I concentrated in optimization and numerical analysis for my undergrad degree in Math, and I'm still surprised on a regular basis how many programmers out there don't know about the inaccuracies and errors that come out of floating-point representations.
Re: Ahah, Apple does have different math
#6This isn't a new problem. The 80-bit internal 8087 FPU precision has always been a mismatch for the 64 bit IEEE double representation, even before the presence of SSE registers (which don't have the 80 bit mode) complicated things. Intel 8087 code has always been able to produce different results for the same source code, depending on when/whether/which intermediate results get spilled to memory. The Motorola 68k FPU had the same issue with higher internal than external precision, IIRC.
This isn't a bug. Both code paths produce results of the highest representable precision of the hardware in question. It's just that there are multiple hardware units capable of giving you the answer, and Apple's toolchain picks a different one than whatever Tom is using elsewhere.
And as has been pointed out in FooBarWidget's comment -- any code that relies on bit-precise results from floating point computation is almost certainly concealing precision bugs anyway. That's not the right way to approach floating point architecture.
Re: Ahah, Apple does have different math
#7Wasn't a very similar phenomenon a huge blow to Intel's PR some years back?
Sort of, but that had to do with a bug in the actual hardware of the Pentium Pro chip:
Re: Ahah, Apple does have different math
#8This shouldn't surprise anyone and I can't say I understand the breathless post. For more information, I recommend Write Great Code: Understanding the Machine -- Chapter 4, Floating-Point Representation.
Re: Ahah, Apple does have different math
#9What Every Computer Scientist Should Know About Floating-Point Arithmetic:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Re: Ahah, Apple does have different math
#10Wasn't a very similar phenomenon a huge blow to Intel's PR some years back?
No, that was not the small errors that are shown here, but rather errors of very significant magnitude.