Date: Wed, 8 Feb 2017 17:27:30 +0000 From: "Montgomery-Smith, Stephen" <stephen@missouri.edu> To: Bruce Evans <brde@optusnet.com.au> Cc: "freebsd-numerics@freebsd.org" <freebsd-numerics@freebsd.org> Subject: Re: C11 conformance of casinl-like functions. Message-ID: <2ecd42a5-7fa3-a06e-a1cf-e82961382b46@missouri.edu> In-Reply-To: <20170209014517.Y17120@besplex.bde.org> References: <CAByVWPUvbG78nUoxQQAOTTY9dJa1agjCZo9oO3dShv2U8Q=y0A@mail.gmail.com> <20170208221449.K14261@besplex.bde.org> <CAByVWPXomH1ijy4oUHjw991c_hgyHQU6Zti1j1jYutxuHE4jcw@mail.gmail.com> <0256e890-05ca-6a1b-9635-88034c544724@missouri.edu> <20170209014517.Y17120@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/08/17 09:10, Bruce Evans wrote: > On Wed, 8 Feb 2017, Montgomery-Smith, Stephen wrote: > >> On 02/08/17 06:47, mokhi wrote: >>>> I think you mean acosl, asinl, ... >>> yeah :D >>> >>>> These were implemented quite well in 2012-2013, but not quite >>>> finished, >>>> and not committed. Only the float and double version were committed. >>>> The raw versions are still available in >>>> https://people.freebsd.org/~stephen/catrig*.c. These have rotted and >>>> require some editing. Compare with the committed parts to see most >>>> of the necessary editing. >>> Okay, I'll do. >>> Would you like that I add you on Phabricator for reviewing when my >>> editing is done? >>> >>> Thanks and best wishes, Mokhi. >> >> I would love to see these functions implemented. I spent a lot of time >> on them, and they went through a lot of testing to make sure they were >> accurate, even in very extreme edge cases. > > It was you that implemented them :-). Except for many onerous details > like testing on all supported arches and committing them. > >> Here are more details about the implementation. >> >> http://faculty.missouri.edu/~stephen/software/#catrig > > It says that the the results are good to 4 ulps except in float precision= . > I dout that that is correct. Higher precisions are just less likely to > get near the corner cases where the errors are larger. > > Corner cases are probably only near zeros and poles, but I test the > real and imaginary parts separately and this gives a dubious size for > an ulp (for the error relative to each part instead of relative to > the absolute value of the result). This gives 1-dimensional sets of > corner cases. The functions try to get a small error by this measure > and mostly succeed. > > Bruce I did some very extensive testing. In fact, I was able to find an edge=20 case in which the paper by Hull, Fairgrieve and Tang had a mistake if=20 one measured the real and imaginary parts separately for cacos/cacosh.=20 I corrected this in the Boost library:=20 https://svn.boost.org/trac/boost/ticket/7290 The algorithm in the paper by Hull, Fairgrieve and Tang would compute=20 cacos(1.00000002785941 + I*5.72464869028403e-200) as (approximately) 0 - I*0.000236048349018331 whereas it should be (approximately) 2.42520172707401e-196 - I*0.000236048349018331. (This is not only close to a zero of acos, I think it is also the end of=20 a branch point.)=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2ecd42a5-7fa3-a06e-a1cf-e82961382b46>