From owner-cvs-all@FreeBSD.ORG Sun Feb 27 02:35:39 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B822516A4CE; Sun, 27 Feb 2005 02:35:39 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59B0843D3F; Sun, 27 Feb 2005 02:35:39 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j1R2ZDtC078009; Sat, 26 Feb 2005 21:35:13 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j1R2ZDtq078008; Sat, 26 Feb 2005 21:35:13 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sat, 26 Feb 2005 21:35:13 -0500 From: David Schultz To: "M. Warner Losh" Message-ID: <20050227023513.GA77813@VARK.MIT.EDU> Mail-Followup-To: "M. Warner Losh" , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200502240632.j1O6WDP9029589@repoman.freebsd.org> <20050226023149.GA63314@VARK.MIT.EDU> <20050226.180549.113100483.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050226.180549.113100483.imp@bsdimp.com> cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/msun/src e_expf.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 02:35:40 -0000 On Sat, Feb 26, 2005, M. Warner Losh wrote: > In message: <20050226023149.GA63314@VARK.MIT.EDU> > David Schultz writes: > : On Thu, Feb 24, 2005, David Schultz wrote: > : > das 2005-02-24 06:32:13 UTC > : > > : > FreeBSD src repository > : > > : > Modified files: > : > lib/msun/src e_expf.c > : > Log: > : > Revert rev 1.8, which causes small (e.g. 2 ulp) errors for some > : > inputs. The trouble with replacing two floats with a double is that > : > the latter has 6 extra bits of precision, which actually hurts > : > accuracy in many cases. All of the constants are optimal when float > : > arithmetic is used, and would need to be recomputed to do this right. > : > : This is related to a good reason why we can't switch the default > : precision on i386 to extended. Many of the functions in libm use > : minimax approximations, which are ``optimal'' approximations in > : the sense that their maximum error over all in-range inputs is the > : smallest possible (unless more terms are used). These approximations > : take rounding error into account, so when the machine precision is > : increased, they're no longer optimal and the error in the approximation > : can increase significantly. There are less efficient methods that > : don't depend on the exact machine precision, e.g. Chebyshev > : approximations, but it would be a PITA to switch everything. > > I guess it comes down to which is more important: long double working > outside of the double range, or small errors in these functions. I > think the former is, but will defer to those with greater floating > point foo. Since to make long double working by setting extended mode > in the application would also break things in the manner you describe. Setting extended mode in applications often works poorly because gcc has been trained to fold constants at double precision in FreeBSD. Also, the errors in libm functions aren't always small or negligible. For instance, consider that the fma() function can be used to compute a 104-bit product of two doubles x and y as follows: p_hi = x * y; p_lo = fma(x, y, -p_hi); The result is that p_hi has the upper 52 bits of the product, and p_lo has the lower 52 bits. But with sometimes-extended-precision doubles on i386, the above mathematical identity, as well as the fma() implementation itself, break. The result is that you get potentially only half as many bits as you thought you had. As you mention, the question is whether it is the people doing naive things or the people doing sophistocated things who get the wrong answer. Before I understood the full implications of setting the default to extended precision, I thought the people who in the second category should get the wrong answer, but now I'm not so sure. On the bright side, very few people have noticed the problem in the last decade, and once amd64 takes over the world, nobody will care anymore at all. ;-)