From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6495 invoked by alias); 29 Apr 2013 20:58:20 -0000 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 Received: (qmail 6433 invoked by uid 55); 29 Apr 2013 20:58:17 -0000 From: "joseph at codesourcery dot com" To: glibc-bugs@sourceware.org Subject: [Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions Date: Mon, 29 Apr 2013 20:58: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: enhancement X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 2.18 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 X-SW-Source: 2013-04/txt/msg00247.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14412 --- Comment #44 from joseph at codesourcery dot com 2013-04-29 20:58:15 UTC --- On Mon, 29 Apr 2013, bugdal at aerifal dot cx wrote: > I don't have a copy of the latest IEEE 754 on hand (there's no free online > version), but the consensus among implementors seems to be that a few special > functions (such as sqrt) require correct rounding, and that the remaining > functions (mostly transcendental) are required to give results with less than > 1ulp of error. If sin(0x1p1000) is computed with incorrect argument reduction, > it may have up to approximately 1e16 ulp error. IEEE 754-2008, subclause 5.4 "formatOf general-computational operations", specifies squareRoot and fusedMultiplyAdd on the same basis as addition, subtraction, multiplication, division, convertFromInt, various operations converting to integer formats and a range of other operations. As the 2008 revision, these are "formatOf" operations (so including e.g. fused multiply-add of long double values, rounded once to float as the destination format), which do not necessarily have C bindings as of C11 - for the formatOf bindings you need DTS 18661-1. Those operations are fully defined. C11 Annex F for sqrt says "sqrt is fully specified as a basic arithmetic operation in IEC 60559. The returned value is dependent on the current rounding direction mode." (F.10.4.5) and similarly for fma (F.10.10.1) says "fma(x, y, z) computes xy + z, correctly rounded once.". For most functions, not fully defined in IEEE 754 or C11, no specific accuracy requirements are imposed, although there are requirements on particular special cases in Annex F. That is, Annex F leaves the implementation-defined accuracy from 5.2.4.2.2 paragraph 6 for most of the functions. IEEE 754-2008 clause 9 "Recommended operations" lists a range of other functions with the requirement "A conforming function shall return results correctly rounded for the applicable rounding direction for all operands in its domain.". These include, for example, both sin and sinPi (sine of pi times the argument). There are no ISO C bindings for these operations at present. I believe the intent is that TS 18661-4 will specify bindings to them, using names such as crsin for the correctly rounding functions (while probably adding names such as sinpi for non-correctly-rounding versions). I believe the intent is that the correctly-rounding versions will be optional for implementations of TS 18661-4. (The exhaustive searches required to prove correctly-rounding, bounded-resource-use implementations of various functions are as far as I know still not feasible for binary128, for example, and correct rounding without arbitrary-precision computation is particularly hard for functions of multiple arguments.) I don't know where the idea of a 1ulp limit on errors being some sort of IEEE requirement came from. As far as I'm concerned, sin(0x1p1000) giving a result that is "reasonably close" (say a few ulp) to the actual sine of 0x1p1000 is a matter of quality of implementation, and giving a result that isn't wildly different is a matter of meeting the requirement that sin implements the sine function rather than some other function that returns random numbers for large inputs. (For some of the additional functions in ISO 24747, the results for large values of certain inputs are specified as implementation-defined because of perceived difficulty of implementing the functions accurately for large inputs. But none of the functions in C11 itself have such latitude to do something arbitrary for large inputs.) -- 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.