Date: Sun, 23 Sep 2012 10:37:01 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Stephen Montgomery-Smith <stephen@missouri.edu> Cc: freebsd-numerics@FreeBSD.org Subject: Re: Complex arg-trig functions Message-ID: <20120923094809.O2556@besplex.bde.org> In-Reply-To: <505E3AE6.2010006@missouri.edu> References: <5017111E.6060003@missouri.edu> <50562213.9020400@missouri.edu> <20120917060116.G3825@besplex.bde.org> <50563C57.60806@missouri.edu> <20120918012459.V5094@besplex.bde.org> <5057A932.3000603@missouri.edu> <5057F24B.7020605@missouri.edu> <20120918162105.U991@besplex.bde.org> <20120918232850.N2144@besplex.bde.org> <20120919010613.T2493@besplex.bde.org> <505BD9B4.8020801@missouri.edu> <20120921172402.W945@besplex.bde.org> <20120921212525.W1732@besplex.bde.org> <505C7490.90600@missouri.edu> <20120922042112.E3044@besplex.bde.org> <505CBF14.70908@missouri.edu> <505CC11A.5030502@missouri.edu> <20120922081607.F3613@besplex.bde.org> <20120922091625.Y3828@besplex.b! de.org> <505D1037.8010202@missouri.edu> <20120922142349.X4599@besplex.bde.org> <20120923044814.S1465@besplex.bde.org> <505E2575.6030302@missouri.edu> <505E27CE.3060107@missouri.edu> <20120923073807.K2059@besplex.bde.org> <505E3AE6.2010006@missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Sep 2012, Stephen Montgomery-Smith wrote: > On 09/22/2012 04:47 PM, Bruce Evans wrote: >> On Sat, 22 Sep 2012, Stephen Montgomery-Smith wrote: >> >>> 2. In my accuracy tests for casin(h), I have never seen the double or >>> long double have an error greater than 4 ULP. But for the float case >>> I have seen 4.15 ULP. >> >> I haven't seen any larger than 3.4. What is the worst case you found? >> Errors found for float precision tend to be because the density of bad >> cases is higher so it is easier to test more of them accidentally. I >> did do some non-random testing for all float cases in narrow strips >> about x or y = 0 or 1, but not for all combinations of this with all >> functions. > > Here are some examples for float. In all these outputs: > The first entry is the "count". > The second entry is the function. > The third and fourth entries are the real and imaginary part of the error in > ULP. > The fifth and sixth entries are the real and imaginary part of the input. > The seventh and eighth and ninth and tenth entries are the real part and > imaginary part of the answers from the float/double respectively (printed to > few enough decimal places that you cannot tell they are different.) > > 2365614 acos 3.75621 0.86681 1.0338860750198364258 -0.090228326618671417236 > 0.246582 0.361712 0.246582 0.361712 > 3087248 acos 3.56538 0.1165 2.3730618953704833984 0.26976472139358520508 > 0.124496 -1.51821 0.124496 -1.51821 > 5973027 asinh 3.61544 0.513 0.10977014899253845215 0.48254761099815368652 > 0.124712 0.499309 0.124712 0.499309 > 6558511 acosh 3.57286 0.419525 -0.29658588767051696777 > -0.11975207924842834473 0.124975 -1.8695 0.124975 -1.8695 > 9998127 acos 3.51324 1.09793 1.0892471075057983398 -0.12541522085666656494 > 0.247452 0.491951 0.247452 0.491951 > 14879751 asinh 3.5643 1.83067 -0.11303693056106567383 0.4351412653923034668 > -0.124994 0.446448 -0.124994 0.446448 > 19510082 asin 3.61922 0.0103899 0.46096378564834594727 > -0.01612871512770652771 0.478995 -0.0181731 0.478995 -0.0181731 > > I can send more examples on request. I'm not seeing a real pattern here. I think they really are that big. 3.75621 is still below 4, and only slightly higher than the worse case I found for acosf (3.5303). Searching more cases will find slightly worse cases. 4.15 only seems bad because we thought we had 2 or 3. The important thing is to find all cases where the error might blow up and check near them. Also check near cases where the algorithm changes (these tend to be the same). I have no good way for generating the test data for this and have to type it in for each case. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120923094809.O2556>