Date: Sat, 26 Feb 2005 21:35:13 -0500 From: David Schultz <das@FreeBSD.ORG> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/msun/src e_expf.c Message-ID: <20050227023513.GA77813@VARK.MIT.EDU> In-Reply-To: <20050226.180549.113100483.imp@bsdimp.com> References: <200502240632.j1O6WDP9029589@repoman.freebsd.org> <20050226023149.GA63314@VARK.MIT.EDU> <20050226.180549.113100483.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 26, 2005, M. Warner Losh wrote: > In message: <20050226023149.GA63314@VARK.MIT.EDU> > David Schultz <das@FreeBSD.ORG> 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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050227023513.GA77813>