From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27869 invoked by alias); 4 Apr 2012 14:13:23 -0000 Received: (qmail 27858 invoked by uid 22791); 4 Apr 2012 14:13:21 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Apr 2012 14:13:07 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug math/13942] x86 acos inaccurate near 1 Date: Wed, 04 Apr 2012 14:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: math X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00032.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13942 --- Comment #3 from Rich Felker 2012-04-04 14:13:00 UTC --- Hi Joseph, I did some preliminary tests, and that formula does not seem to fix it. Given the following, which has been written in C to use extended precision for intermediate results: double x = 0x0.ffffffffffffp0; printf("%.17g\n", acos(x)); printf("%.17g\n", (double)atanl(sqrtl(1-(long double)x*x))); printf("%.17g\n", (double)atanl(sqrtl((1-(long double)x)*(1+(long double)x)))); I'm getting: 8.4293697021788083e-08 8.4293697021787858e-08 8.4293697021787791e-08 The first result (our current implementation in musl) agrees with Wolfram Alpha's value for acos(0.999999999999996447286321199499070644378662109375). Both of the latter results have relatively huge error. So unless I screwed up something in doing the intermediate results at extended precision, I don't think your solution works. Note that our algorithm avoids performing any multiplication or division that would lose precision. The only loss of precision takes place at the sqrt operations (which will be correctly rounded for extended precision) and the atan operation. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.