Date: Sat, 22 Sep 2012 17:25:42 -0500 From: Stephen Montgomery-Smith <stephen@missouri.edu> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-numerics@freebsd.org Subject: Re: Complex arg-trig functions Message-ID: <505E3AE6.2010006@missouri.edu> In-Reply-To: <20120923073807.K2059@besplex.bde.org> References: <5017111E.6060003@missouri.edu> <5055ECA8.2080008@missouri.edu> <20120917022614.R2943@besplex.bde.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?505E3AE6.2010006>