From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5502 invoked by alias); 29 Apr 2013 15:19:01 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 5482 invoked by uid 89); 29 Apr 2013 15:19:01 -0000 X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,KHOP_DYNAMIC2,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 29 Apr 2013 15:18:59 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1UWpqq-0003RQ-00; Mon, 29 Apr 2013 15:18:48 +0000 Date: Mon, 29 Apr 2013 15:19:00 -0000 To: Andrew Haley Cc: =?utf-8?B?T25kxZllaiBCw61sa2E=?= , "Joseph S. Myers" , Siddhesh Poyarekar , libc-alpha@sourceware.org, libc-ports@sourceware.org Subject: Re: [PATCH][BZ #14412] Define __sincos_finite as a fast version of sincos Message-ID: <20130429151848.GY20323@brightrain.aerifal.cx> References: <20130429102739.GE1330@spoyarek.pnq.redhat.com> <20130429141553.GC24033@domone.kolej.mff.cuni.cz> <517E894C.8090602@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <517E894C.8090602@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) From: Rich Felker X-SW-Source: 2013-04/txt/msg00110.txt.bz2 On Mon, Apr 29, 2013 at 03:53:00PM +0100, Andrew Haley wrote: > On 04/29/2013 03:15 PM, Ondřej Bílka wrote: > > On Mon, Apr 29, 2013 at 01:34:42PM +0000, Joseph S. Myers wrote: > >> On Mon, 29 Apr 2013, Siddhesh Poyarekar wrote: > >> > >>> This patch brings back the assembly implementation of sincos (with > >>> some changes) to give a fast alternative to the default sincos > >>> implementation. This is defined as __sincos_finite and is used if the > >>> implementing program is compiled with the -ffinite-math-only gcc flag. > >> > >> The changes don't seem to include accurate range reduction. Without that, > >> I think this is inappropriate, as it will result in wildly inaccurate > >> results for large but finite inputs. > >> > > These inputs contain zero significant digits. You cannot expect any > > accuracty from them. > > You can't possibly know that. If the caller asks for sin(2^80) you should > return a close approximation to sin(2^80), not garbage. Ondřej is simply repeating the standard fallacy from people who think floating point numbers represent intervals or some sort of approximation with a distribution of possible "actual values" centered on the nominal value. These views are all incorrect. Floating point values are always exact values. Floating point _calculations_, including conversion from decimal strings, can be inexact, but the values represented, and used as inputs to floating point functions and operators, are exact. Rich