public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Paul Zimmermann <Paul.Zimmermann@inria.fr>
To: Carlos O'Donell <carlos@redhat.com>
Cc: libc-alpha@sourceware.org, joseph@codesourcery.com
Subject: Re: largest known errors
Date: Thu, 14 Dec 2023 09:05:45 +0100	[thread overview]
Message-ID: <p9u0jzphus2u.fsf@coriandre.loria.fr> (raw)
In-Reply-To: <783d18da-a3bf-179d-9961-70aed5f368e5@redhat.com> (message from Carlos O'Donell on Wed, 13 Dec 2023 12:42:11 -0500)

       Hi Carlos,

> Date: Wed, 13 Dec 2023 12:42:11 -0500
> From: Carlos O'Donell <carlos@redhat.com>
> Organization: Red Hat
> 
> On 12/13/23 03:49, Paul Zimmermann wrote:
> >        Hi,
> > 
> > on https://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html it is written:
> > 
> > "The table lists the maximum error for each function which is exposed by one of the existing tests in the test suite." [*]
> > 
> > Function i686 ix86 x86_64
> > j0f      9    9    9
> > j0       5    5    3
> > 
> > As a consequence, people conclude that the maximum error is 9 ulps for all
> > GNU libc functions, see https://dl.acm.org/doi/pdf/10.1145/3624062.3624166
> > end of page 893, right column.
> 
> In general they would be correct to assume that given the manual information.
> 
> > But we know the largest error for j0 on x86_64 is at least 4.51e14 ulps [1].
> > See also https://sourceware.org/bugzilla/show_bug.cgi?id=27670.
> > Moreover the test suite contains many "xfail" entries, for example:
> > 
> > j0 0x1.31ec02p+1 xfail:binary64
> > 
> > If one adds j0 0x1.33d152e971b4p+1 in auto-libm-test-in and reruns make
> > regen-ulps, one gets as output:
> > 
> > Failure: Test: j0 (0x2.67a2a5d2e368p+0)
> > Result:
> >  is:         -5.7480381767140581e-17  -0x1.0914db68ef3e2p-54
> >  should be:  -6.1087652597367303e-17  -0x1.19b7921f03c8ep-54
> >  difference:  3.6072708302267220e-18   0x1.0a2b6b6148ac0p-58
> >  ulp       :  292656578119852.0000
> >  max.ulp   :  3.0000
> > 
> > but the final result says:
> > 
> > Test suite completed:
> >   0 test cases plus 0 tests for exception flags and
> >     0 tests for errno executed.
> >   All tests passed successfully.
> > 
> > I believe we should amend the sentence [*], and/or replace the bounds that we
> > know are wrong by some special value, say U for Unbounded.
> 
> There are two issues here and the nuances around them matter to me.
> 
> (a) There are known defects where ULPs may reach values that are not useful
>     for talking about the library in general.
>
> (b) There is value in being clear about the worst case known ULPs for an
>     implementation of a given algorithm.
> 
> If a test is marked as XFAIL then it is clearly (a) and listing that worst
> case ULPs in the manual may not be useful.
> 
> If the test is not marked as XFAIL then it is clearly in (b) and we should
> list it in the manual as the worst case known ULPS because that is what
> the currently implemented algorithm does.
> 
> Lastly, all XFAIL entries should reference bugs in our bug tracker, and
> if they don't then we should create them to track and resolve the bug.
> 
> In closing...
> 
> How might we amend the sentence to better explain (a) and (b)?

so that the manual gives accurate information, one solution would be to write
"The table lists the maximum known error for each function, apart
known defects for some functions and some architectures", and then reference
the bugs corresponding to the known defects.

If we don't want to list all bugs, another possibility would be to replace
the bound by some special value (say NA) that would mean the maximum known
error exceeds the target value. This would concern only a few functions, for
example j0/j1/y0/y1/lgamma in double precision for x64_64 according to
Table 3 of https://members.loria.fr/PZimmermann/papers/accuracy.pdf.

Paul

      parent reply	other threads:[~2023-12-14  8:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13  8:49 Paul Zimmermann
2023-12-13 17:42 ` Carlos O'Donell
2023-12-13 21:40   ` Joseph Myers
2023-12-14  8:25     ` Paul Zimmermann
2023-12-14  8:05   ` Paul Zimmermann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=p9u0jzphus2u.fsf@coriandre.loria.fr \
    --to=paul.zimmermann@inria.fr \
    --cc=carlos@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).