This is the mail archive of the
`libc-alpha@sourceware.org`
mailing list for the glibc project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Zack Weinberg <zackw at panix dot com>*To*: Ondřej Bílka <neleai at seznam dot cz>*Cc*: Siddhesh Poyarekar <siddhesh at gotplt dot org>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>*Date*: Fri, 9 Mar 2018 13:52:00 -0500*Subject*: Re: [PATCH 2/6] Remove slow paths from sin/cos*Authentication-results*: sourceware.org; auth=none*References*: <DB6PR0801MB2053788EB64591EC936E598683DE0@DB6PR0801MB2053.eurprd08.prod.outlook.com> <8065ca77-ec8f-9925-7e9c-52266cd1e4c6@gotplt.org> <20180309181902.GA26430@domone>

On Fri, Mar 9, 2018 at 1:19 PM, Ondřej Bílka <neleai@seznam.cz> wrote: > On Fri, Mar 09, 2018 at 09:47:09PM +0530, Siddhesh Poyarekar wrote: >> On Friday 09 March 2018 09:16 PM, Wilco Dijkstra wrote: >> > This patch removes 2nd of the 3 range reduction cases and defer to the final one. >> > Input values above 2^27 are extremely rare, so this case doesn't need to as be >> > optimized as smaller inputs. >> >> Please elaborate on two more points: >> >> - The basis for your claim that values above 2^27 are extremely rare, >> i.e. papers that you may have referred that conclude this and/or >> applications you may have profiled >> > Main reason is that for these inputs accuracy doesn't make a sense. > There is already millions bigger error caused by limited precision when > rounding input to float. More concretely, for IEEE single, the gap between representable values is bigger than 2π for values whose exponent is 2^26 or above. Since the sine function is periodic over 2π, that means the result of sinf() is effectively meaningless for any input at least that big - _any value_ within the input period could have been rounded to the representable, so the "true" answer could be anything. (I am tempted to suggest that we return NaN for inputs this large, without even bothering to do argument reduction.) For double, this happens at 2^55, and for x86-64 long double it happens at 2^66. I _think_ x86-64 long double is 80-bit IEEE extended, not quad, but I could be wrong. zw

**Follow-Ups**:**Re: [PATCH 2/6] Remove slow paths from sin/cos***From:*Steve Ellcey

**References**:**[PATCH 2/6] Remove slow paths from sin/cos***From:*Wilco Dijkstra

**Re: [PATCH 2/6] Remove slow paths from sin/cos***From:*Siddhesh Poyarekar

**Re: [PATCH 2/6] Remove slow paths from sin/cos***From:*Ondřej Bílka

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |