
Intel Underestimates Error Bounds by 1.3 quintillion (2014) - sgillen
https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/
======
jabl
Worth noting this is for the x87 fsin instruction. For x86_64 typically a
library function is called (which in turn uses SSE2 math instead of x87)
rather than generating inline code.

~~~
ajross
More "pervasively" than merely typically. The x87 registers still exist in a
technical sense, but except for compatibility in legacy binaries those
instructions are never used.

~~~
burfog
They are used by gcc on x86_64 Ubuntu when dealing with long double. I just
tried it, with a trivial function that adds arguments and returns the
resulting sum.

I think this is true on any x86_64 platform for which sizeof(long double)
exceeds 8.

~~~
ajross
Sure, because "long double" is fundamentally an x86-specific compiler
extension[1] designed to exploit the 80 bit FPU precision in the 8087
architecture. Nothing for an SSE (or any other 64 bit IEEE FPU) will be using
long double, except for compatibility.

[1] Yeah, I think there's a software emulation layer to give you 128 bits on
other platforms or somesuch. Again, not important nor relevant to a discussion
abou FSIN.

------
faragon
Take attention to the "References" section (including references to Linus
Torvalds messages in the GCC mail list, some bugs related to this issue, etc.)

~~~
acqq
Yes. It obviously shows where Linus steps out of the bounds in which he is an
expert. He blindly believes Intel's false documentation as early as 2001, and,
if I understood correctly, the result is that glibc has bad FP sin for quite a
while, since the maintainers also don't try to check anything, and:

\- either there was no user who seriously used it (to detect the error)

\- or the user who seriously used the sin and detected the error didn't pass
through the maintainers' "wall blocking the casual contributions" (a major
maintainer for a few years was kind of legendary for being very dismissive and
hard to communicate with).

\- or the detector of the error remained silent.

It seems that Bruce was the first managing to induce the change in glibc, and
he needed to reach Intel first for that.

Linus being wrong in believing the documentation instead of checking it
himself:

[https://gcc.gnu.org/ml/gcc/2001-08/msg00679.html](https://gcc.gnu.org/ml/gcc/2001-08/msg00679.html)

I'm curious when Java fixed their bad assumptions:

[https://bugs.java.com/view_bug.do?bug_id=4306749](https://bugs.java.com/view_bug.do?bug_id=4306749)

It seems much faster, as already in 2005 Gosling knew the truth:

[https://web.archive.org/web/20110812023545/https://blogs.ora...](https://web.archive.org/web/20110812023545/https://blogs.oracle.com/jag/entry/transcendental_meditation)

"the x87 fsin/fcos use a particular approximation to pi, which effectively
means the period of the function is changed, which can lead to large errors
outside [-pi/4, pi/4]."

"What we do in the JVM on x86 is moderately obvious: we range check the
argument, and if it's outside the range [-pi/4, pi/4]we do the precise range
reduction by hand, and then call fsin."

Gosling actually quotes "Joe Darcy, our local Floating Point God."

Joseph D. Darcy was also a co-author of:

"How Java's Floating-Point Hurts Everyone Everywhere" with W. Kahan
([http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf](http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf))

and his master thesis was:

"Borneo: Adding IEEE 754 floating point support to Java"
[http://sonic.net/~jddarcy/Borneo/](http://sonic.net/~jddarcy/Borneo/)

"a dialect of the Java language designed to have _true support for the IEEE
754_ floating point standard." "Unfortunately, Java's specification creates
several problems for numerical computation" ... "useful IEEE 754 features are
either explicitly forbidden or omitted from the Java specification."

~~~
IshKebab
To be fair he did say "assuming they don't have an fdiv-like bug ;)"

~~~
acqq
> he did say "assuming they don't have an fdiv-like bug

The actual situation was not too similar: the instruction that should speed up
the calculation and returning the correct bits in the specific range, actually
behaves as intended, that is, the designers of the instruction assumed the
users will know the limitation of it, that is, it was originally assumed that
the users were supposed to know that the function is not the "general" one and
the "bug" was just in the misleading documentation. By fdiv you've had an
instruction that didn't behave as intended, being wrong for some very specific
inputs and not only outside of the designed range.

------
known
Floating Point Math
[http://0.30000000000000004.com/](http://0.30000000000000004.com/)

------
Dylan16807
So is it wrong to me to interpret this as an imprecision of a partial ULP on
the _input_ number, thereby making the accuracy of the output just fine?

Is there a use case for such a numerically unstable function use except as a
party trick to get pi?

~~~
brucedawson
The input number is, unavoidably, not a perfect representation of pi. However
the fsin instruction's job is to calculate the sin of the actual input number,
not try to guess what input was intended.

So it doesn't make sense to interpret this as an imprecision of the input
number - the fsin instruction failed to give a result which was as accurate as
its documentation promised. The documentation has been fixed now.

I don't know how often this actually matters, but it's worth nothing that
library implementations of sin() don't use fsin anymore, and I think that is
partially because of this flaw.

~~~
Dylan16807
> However the fsin instruction's job is to calculate the sin of the actual
> input number, not try to guess what input was intended.

Not guessing what was 'intended', just treating a number like "1.234567" as
"any number that could have rounded to 1.234567000, whatever is most
convenient". Does it cause any practical problems to do this? How often do
people actually expect/need a double to be treated as having infinite
precision, rather than 53 bits or slightly more than 53 bits of precision?

------
bsder
Um, it was known at least as far back as the AMD K5 (which has something like
300+ bits of Pi) that argument reduction on x86 didn't have enough bits of Pi.

~~~
londons_explore
You need _a lot_ of bits of pi if you want to have an even vaguely accurate
result when you do sin(MAX_DOUBLE)

------
aurelien
"Not so much!" ~Intel motto

------
stilley2
From 2014, FYI

~~~
dang
Thanks, added.

------
inetknght
What's that? Floating point math strikes again? /s

Let's build something better.

~~~
AceJohnny2
IEEE 754 is one of the rare successes of computer engineering and
standardization.

Turns out it's just _hard_ to implement continuous math on physical hardware.

I'm curious (and a bit skeptical) about any efforts that think they can do
better.

~~~
triska
John Gustafson has developed several promising alternatives, such as _unums_ ,
_posits_ and _valids_ :

[https://posithub.org/about](https://posithub.org/about)

I also recommend his book, _The End of Error - Unum Computing_ :

[https://www.crcpress.com/The-End-of-Error-Unum-
Computing/Gus...](https://www.crcpress.com/The-End-of-Error-Unum-
Computing/Gustafson/p/book/9781482239867)

A transcript of a debate with William Kahan is here:

[http://www.johngustafson.net/pdfs/DebateTranscription.pdf](http://www.johngustafson.net/pdfs/DebateTranscription.pdf)

