From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6676 invoked by alias); 12 Mar 2018 15:46:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 129382 invoked by uid 89); 12 Mar 2018 15:45:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,TIME_LIMIT_EXCEEDED,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 spammy=H*r:2002 X-HELO: mailbackend.panix.com X-Gm-Message-State: AElRT7EsjQfHokOyPmvAgymJ02stKsh6bgQATbRk9674jLzBPjYn2hkG BIKDeYi+T4rUYpEw5FEgHypvVGo/5g7ZvGchP2w= X-Google-Smtp-Source: AG47ELtF5klquJEjxL1A8DZbB9gBBGdxLa3rYew0AE/jCPioL60GFHwqBDBA1IvfBcbs1LOOoIddQHxDtDt9/XiID1I= X-Received: by 10.157.23.236 with SMTP id j99mr6073618otj.77.1520869514241; Mon, 12 Mar 2018 08:45:14 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1520636722.6774.157.camel@cavium.com> From: Zack Weinberg Date: Mon, 12 Mar 2018 15:46:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] Remove slow paths from sin/cos To: Wilco Dijkstra Cc: Joseph Myers , Steve Ellcey , =?UTF-8?B?T25kxZllaiBCw61sa2E=?= , Siddhesh Poyarekar , "libc-alpha@sourceware.org" , nd Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-03/txt/msg00288.txt.bz2 On Mon, Mar 12, 2018 at 11:36 AM, Wilco Dijkstra wrote: > 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. I think 0.5 ULP error bound for values close to _small_ integer multiples of pi/2 is worth preserving. I'm not sure what the right cutoff is, but if we need to do that "significant extra work" for, like, values close to 10*pi and the most natural way to implement that also gives us the same error bound for values close to 1e6*pi, then I don't see why we shouldn't keep it for both. zw