From owner-freebsd-numerics@FreeBSD.ORG Fri Aug 23 11:12:48 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C9D518D1 for ; Fri, 23 Aug 2013 11:12:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 44E092EBC for ; Fri, 23 Aug 2013 11:12:48 +0000 (UTC) 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 mail109.syd.optusnet.com.au (Postfix) with ESMTPS id CD9D9D62E77; Fri, 23 Aug 2013 21:12:34 +1000 (EST) Date: Fri, 23 Aug 2013 21:12:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl Subject: Re: (2nd time) tweaks to erff() threshold values In-Reply-To: <20130822213315.GA6708@troutmask.apl.washington.edu> Message-ID: <20130823202257.Q1593@besplex.bde.org> References: <20130822213315.GA6708@troutmask.apl.washington.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.1 cv=DstvpgP+ c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=F6uwjYSw4mAA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=bRjWgPqadKYA:10 a=0q7wHxVP66BF9WyAtZ0A:9 a=9vR6l-q_0Ft0s3_N:21 a=6bBav436BQXeBPxM:21 a=CjuIK1q_8ugA:10 Cc: freebsd-numerics@FreeBSD.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 11:12:48 -0000 On Thu, 22 Aug 2013, Steve Kargl wrote: > (Having problems with freebsd-numerics list. Hopefully, not > a duplicate.) It was a duplicate :-). > I would like to apply the patch, which follows my .sig, > to msun/src/s_erff.c. It tweaks the threshold values > to those appropriate for erff(). > ... > Index: src/s_erff.c > =================================================================== > --- src/s_erff.c (revision 1358) > +++ src/s_erff.c (working copy) > @@ -107,10 +107,10 @@ > } > > if(ix < 0x3f580000) { /* |x|<0.84375 */ > - if(ix < 0x31800000) { /* |x|<2**-28 */ > - if (ix < 0x04000000) > + if(ix < 0x39000000) { /* |x|<2**-13 */ This increases the number of incorrectly rounded cases slightly on i386, but 2**-14 decreases it slightly. This is because i386 has extra precision for floats which the nonlinear return expression can actually use for approx. 2**-14 < |x| < 2**-13. > + if (ix < 0x04000000) /* |x|<0x1p-119 */ > /*avoid underflow */ > - return (float)0.125*((float)8.0*x+efx8*x); > + return (8*x+efx8*x)/8; Also put the comment back on the same line as the return statement now that it fits again (see the double version). Also add "spurious" to the comment. Underflow still occurs for most denormal x. This is non-spurious. We just avoid it for |x| larger than about 8 times the largest denormal, by multiplying efx by 8 so that it is larger than 1 (efx8 = 8(efx)). A recent discussion in comp.std.c made me more aware that underflow is mishandled for most functions in libm. They need to use something like the above to handle it correctly. For example, sin(x) returns x with inexact for denormal x, but it should return x with inexact AND UNDERFLOW for denormal x, since x is only an approximation to sin(x) -- the exact result is slightly smaller in magnitude in x, so is "tiny" when x is, and underflow means tiny plus inexact. The above still fails to raise underflow if 8*x, efx8*x, and their sum are all exact. 8*x is exact if x has 3 lower bits 0, which is quite often, and the others are rarely exact, except on i386 without clang everything is always exact since it is in extra precision. In nonstandard rounding modes, sin(x) shouldn't be rounded to x, but fdlibm and FreeBSD don't try to support such rounding modes for most functions including sin(). If they were supported, then they would increase the complications for underflow. IEEE x54 allows 2 alternatives for underflow. One is when the result is tiny after rounding, and inexact, and the other is when the result is tiny before rounding, and inexact. This causes complications even in round-to-nearest mode. Consider sin(x) on the largest denormal. The result of x is tiny both before and after rounding, and inexact, so underflow should be rasied. Consider sin(x) on the smallest normal. The result of x is normal after rounding, so is not tiny, but before rounding it is smaller than the smallest normal so should probably be considered as "tiny", so underflow should be raised iff it depends on tinyness before rounding. The discussion on comp.std.c was mainly about how extra precision complicates things further. When an expression like (8*x+efx8*x)/8 is evaluated in extra precision, nothing is tiny, so underflow is not raised. Inexact is probably not raised either for this particular expression. Underflow should be raised iff the extra precision is discarded, but the information for raising it has been partly lost. It will only be raised on conversion if the result is "tiny" then (before or after rounding) and is inexact THEN. It is inexact then iff any of the low bits that are discarded is nonzero. But sometimes the extra-precision result makes all these bits zero and discards nonzero bits even further out. The delayed conversion cannot do the right thing since it doesn't know about the bits already discarded. C standards get this wrong by having strict requirements for raising underflow. It is very difficult to raise it exactly when specified. C standards don't have strict requirements for raising inexact because they know about this problem for inexact. But underflow is even harded to decide than inexact. Implementations that support trapping of overflows have additional complications. IEEE x54 specifies that if traps for underflow are enabled, then underflow traps occur iff the result is tiny, while the underflow exception is raised iff the result is tiny and inexact. Thus, underflow traps, if enabled, occur more often than underflow exceptions. The trapped case is simpler but different (if the trap handler handler just returns). C standards don't support trapping of FP exceptions, and are even further from supporting returning from trap handlers. > return x + efx*x; > } > z = x*x; > ... Some modified lines: @ if(ix < 0x3f580000) { /* |x|<0.84375 */ @ if(ix < 0x38800000) { /* |x|<2**-14 */ @ if (ix < 0x04000000) /* |x|<0x1p-119 */ @ return (8*x+efx8*x)/8; /*avoid spurious underflow */ @ } @ return x + efx*x; @ } The whole erf implementation is probably not the best way for float precision, but is good for understanding higher precisions. Bruce