This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] S/390: ULPs update
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, <libc-alpha at sourceware dot org>
- Date: Fri, 19 Jul 2013 17:15:34 +0000
- Subject: Re: [PATCH] S/390: ULPs update
- References: <20130719083812 dot GA25383 at bart> <51E96223 dot 6090703 at redhat dot com>
On Fri, 19 Jul 2013, Carlos O'Donell wrote:
> For jn you've got 8 ulp in long-double which is rather
> high.
That's within the normal range for jn.
> You've also got 5 ulp in cpow for float but not
> double or long double, which is odd.
cpow is known to be inaccurate; I wouldn't worry about 5ulp there.
> Also 5 ulp in ctan_* is a little high.
It's within the normal range for lots of functions in directed rounding
modes.
I've wondered if libm-test.inc should simply not output some excessive
ulps to the ULPs file, so you don't need to remove them manually when you
have known bugs causing large errors, but I was thinking more in terms of
50 or 100 ulps as the boundary for "excessive" there (or 1ulp for
functions that should always be correctly rounded). (The largest ulps in
libm-test-ulps files I'm confident are still current are 13 for powerpc
for IBM long double in directed rounding modes. m68k has some ulps up to
19, but the recent update wasn't from scratch so those may be obsolete.
And ia64 and sh have some 24ulp values but those ulps files haven't been
updated / regenerated for years.)
--
Joseph S. Myers
joseph@codesourcery.com