This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Documenting libm function errors
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: James Courtier-Dutton <james dot dutton at gmail dot com>
- Cc: Andrew Haley <aph at redhat dot com>, Richard Guenther <richard dot guenther at gmail dot com>, Geert Bosch <bosch at adacore dot com>, gcc at gcc dot gnu dot org, libc-alpha at sourceware dot org
- Date: Fri, 10 Feb 2012 14:01:04 +0000 (UTC)
- Subject: Documenting libm function errors
- References: <CADn89gRRwQ5uPGCDMGZo28ofnAQsvU5PURKxPuvOPF1+ZbvO8g@mail.gmail.com><Pine.LNX.4.64.1202031647020.25409@wotan.suse.de> <20120203162402.GE5312@xvii.vinc17.org><Pine.LNX.4.64.1202031738430.25409@wotan.suse.de> <20120203214853.GG5312@xvii.vinc17.org><CAAMvbhGYDB717P8pux5nT-Hw3_NQq7k3HRD=vGTtb9Y+2mzpkg@mail.gmail.com><4F33A16B.7010507@redhat.com> <CAFiYyc1c-qscpC=YrVbEJKa_D-zF88-xbw-wub+jhbRNfFW4Dw@mail.gmail.com><4F33CC70.3040401@aol.com> <4F33CE33.4000204@redhat.com><E2293D0E-CDD6-4126-8EF2-25C75CFCE1C4@adacore.com><CAFiYyc2d7h5=EshA6BEr=QGeSJgCVzTCAHpN9ZS7w-zqjwqAeg@mail.gmail.com><5CEA5397-B4FB-4E5F-B915-E67887C0D68E@adacore.com><Pine.LNX.4.64.1202091742130.3326@digraph.polyomino.org.uk><3809CC7F-E789-42CB-98A6-A774BEDA3109@adacore.com><CAFiYyc1+6ioVYX-suMyhG9s9Tv06SMSmjBugKRxSvoz4on36yA@mail.gmail.com><4F34F4B3.6020102@redhat.com> <CAAMvbhE79bX5HSmdmMDj6qzEezNYDxwij05Wrn2d6juiLT0r2A@mail.gmail.com>
[Including libc-alpha on discussion starting on the gcc list.]
On Fri, 10 Feb 2012, James Courtier-Dutton wrote:
> I think a starting point would be at least documenting correctly the
> accuracy of the current libm, because what is currently in the
> documents is obviously wrong.
To the extent that there is documentation I think some of it is
automatically generated from the ULPs files in the glibc testsuite
(manual/libm-err-tab.pl). Apart from the limited information that can be
conveyed by a single number if accuracy varies over the domain of the
function, it's also likely that functions may have a theoretical
justification that gives error bounds that can be relied upon more than
the ones in the ULPs files. Also, libm-err-tab.pl hardcodes a list of
platforms - it would be better for each platform's name for the manual to
go somewhere in its sysdeps directory - and it also seems unfortunate for
the output generated to depend on whether or not the ports add-on is
present (although I don't see a good way to avoid that with this
approach).
> It certainly does not document that sin() is currently more accurate
> than sinl() on x86_64 platforms, even with -O0.
> I think the documentation should be along the lines of for
> Function name: sin(x)
> -pi/2 < x < pi/2, accuracy is +-N
> pi/2 < x < large number, accuracy is +-N
> large number < x < max_float, accuracy is +-N
> If a performance figure could also be added, so much the better. We
> could then know that implementation 1 is quicker than implementation 2
> and the programmer can do the trade offs.
That sort of thing would make sense - though it would be a lot of work to
add for existing functions.
--
Joseph S. Myers
joseph@codesourcery.com