From owner-freebsd-standards@FreeBSD.ORG Thu May 30 16:52:38 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B52D882; Thu, 30 May 2013 16:52:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id B6C2C669; Thu, 30 May 2013 16:52:37 +0000 (UTC) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4UGqRRB032572; Fri, 31 May 2013 02:52:27 +1000 Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4UGqDd8011312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 02:52:14 +1000 Date: Fri, 31 May 2013 02:52:13 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 In-Reply-To: Message-ID: <20130531015915.N65390@besplex.bde.org> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=BPvrNysG c=1 sm=1 a=Qub1x3MNGSYA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=AyPkC9FW8vsA:10 a=gmrSIYXE1WnqeYESaG8A:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: Stephen Montgomery-Smith , pfg@FreeBSD.org, freebsd-numerics@FreeBSD.org, David Schultz , freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:52:38 -0000 On Thu, 30 May 2013, Warner Losh wrote: > I'm all for getting everything we can into the tree that produces an answer that's not perfect, but close. What's the error that would be generated with the naive implementation of > > long double tgammal(long double f) { return tgamma(f); } On x86, 11 low bits wrong, for an error of 2048 ulps, in addition to any errors in tgamma(). tgamma() on i386 inherits errors of 9 peta-ulps (all 53 bits wrong) from i387 trig functions, but is OK on small args on i386 and better on large args on amd64. On sparc64, 60 low bits wrong, for an error of 1 exa-ulp, in addition to any errors in tgamma(); the latter are the same as on amd64. Sparc64 users of long double precision pay for it with a loss of performance of a factor of several hundred, so they should be unhappy to not get he extra bits when they ask for them (but the above inaccurate version doesn't give them what they asked for). On arches with long double == double, no difference. On i386 with the default rounding precision of double, little difference. > But assuming that, for some reason, produces errors larger than difference in precision between double and long double due to extreme non-linearity of these functions, having only a couple of stragglers is a far better position to be in than we are today. Such extra errors normally don't happen. In fact, my accuracy tests for double functions are essentially to upcast the results of double functions and compare the resulting bits with the corresponding results for long double functions. Nonlinearities tend to only happen at zeros and poles of functions and then they are due to bugs, and for NaNs, and then they are due to implementation-defined behaviour. It is difficult to even determine the location of zeros and poles for some functions, and most of the complexities in libm are to uses especially careful calculations near them when they are known. Bruce