5 ms·

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 8y ago
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.oracle.com/jag/entry/transcendental_meditation https://web.archive.org/web/20110812023545/https://blogs.ora... "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 8y ago
  To be fair he did say "assuming they don't have an fdiv-like bug ;)"
  - acqq 8y ago
    > 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.
- brucedawson 8y ago
  > It seems that Bruce was the first managing to induce the change in glibc glibc changed their implementation before I reported on this.

acqq 8y ago

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.oracle.com/jag/entry/transcendental_meditation https://web.archive.org/web/20110812023545/https://blogs.ora... "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 8y ago
To be fair he did say "assuming they don't have an fdiv-like bug ;)"
- acqq 8y ago
  > 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.
brucedawson 8y ago
> It seems that Bruce was the first managing to induce the change in glibc glibc changed their implementation before I reported on this.