This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/6] Remove slow paths from sin/cos
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Steve Ellcey <sellcey at cavium dot com>
- Cc: Zack Weinberg <zackw at panix dot com>, Ondřej Bílka <neleai at seznam dot cz>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Mon, 12 Mar 2018 15:36:41 +0000
- Subject: Re: [PATCH 2/6] Remove slow paths from sin/cos
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- References: <CAKCAbMg85h8JLK1qUNUgUUDVwU2WCnD4WCCputCM7qhr7y0i6w@mail.gmail.com> <1520636722.6774.157.camel@cavium.com>,<alpine.DEB.2.20.1803100049290.28686@digraph.polyomino.org.uk>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Joseph Myers wrote:
> Yes. A floating-point number represents a particular real number, not an
> interval, so all the usual accuracy goals (of results within a few ulps of
> the correct answer) apply for large inputs (but performance is not a
> concern for those inputs). Only for IBM long double is this relaxed, to
> treat values not representable in 106 mantissa bits as if they do
> represent intervals.
Though these patches keep the ULP accuracy across the full range as is,
we could agree on higher ULP errors for large/huge range reduction cases
in the future. The main complexity is for certain rare inputs which happen to
be extremely close to an integer multiple of PI/2, and those few cases mean
you need significant extra work to guarantee 0.5 ULP error bound on range
reduction.
Wilco