Date: Fri, 10 Oct 2014 06:58:43 -0400 From: Yousuf Khan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 Newsgroups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,alt.comp.hardware.pc-homebuilt Subject: Transcendental floating point functions are now unfixably broken on Intel processors Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24-212-231-36.cable.teksavvy.com Message-ID: <5437bbbe$1@news.bnb-lp.com> X-Trace: news.bnb-lp.com 1412938686 24-212-231-36.cable.teksavvy.com (10 Oct 2014 06:58:06 -0400) Organization: Send abuse or DMCA complaints to abuse@bnb-lp.com Lines: 24 X-Authenticated-User: vfa100 X-DMCA-Complaints: Send abuse or DMCA complaints to abuse@bnb-lp.com X-DMCA-Complaints: The subject line should contain only the 4 letters DMCA Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news.bnb-lp.com!not-for-mail Xref: csiph.com comp.sys.ibm.pc.hardware.chips:1287 comp.sys.intel:353 " This error has tragically become un-fixable because of the compatibility requirements from one generation to the next. The fix for this problem was figured out quite a long time ago. In the excellent paper The K5 transcendental functions by T. Lynch, A. Ahmed, M. Schulte, T. Callaway, and R. Tisdale a technique is described for doing argument reduction as if you had an infinitely precise value for pi. As far as I know, the K5 is the only x86 family CPU that did sin/cos accurately. AMD went back to being bit-for-bit compatibile with the old x87 behavior, assumably because too many applications broke. Oddly enough, this is fixed in Itanium. 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. So Java is accurate, but slower. I've never been a fan of "fast, but wrong" when "wrong" is roughly random(). Benchmarks rarely test accuracy. "double sin(double theta) { return 0; }" would be a great benchmark-compatible implementation of sin(). For large values of theta, 0 would be arguably more accurate since the absolute error is never greater than 1. fsin/fcos can have absolute errors as large as 2 (correct answer=1; returned result=-1). " https://blogs.oracle.com/jag/entry/transcendental_meditation