From: Paul Zimmermann <Paul.Zimmermann@inria.fr>
To: Michael Morrell <mmorrell@tachyum.com>
Cc: libc-alpha@sourceware.org
Subject: Re: Fix the inaccuracy of j0f/y0f/j1f/y1f
Date: Sun, 21 Feb 2021 08:37:43 +0100 [thread overview]
Message-ID: <mwa6rxx454.fsf@tomate.loria.fr> (raw)
In-Reply-To: <6cf8704bcd9a45ac82cf23f05aab68a6@tachyum.com> (message from Michael Morrell on Fri, 19 Feb 2021 16:44:02 +0000)
Dear Michael,
> I'm curious about something. Where is it specified what the required accuracy is for a given math function? Before I discovered the libm-test-ulps file, I would have expected a C library to be required to computed the exact result for any defined function (possibly allowing some inaccuracy if -ffast-math were specified). I look through the POSIX spec, but couldn't find any place that mentioned an accuracy requirement.
to complete Joseph's answer:
* the IEEE 754 standard (even in its latest revision from 2019) does not
require "correct rounding" for the mathematical functions (except for
sqrt). More precisely it defines "Additional mathematical operations"
which shall return correctly rounded results, but these operations are
not mandatory. This means that mathematical libraries can do whatever
they want, and in practice they do [1].
* for GNU libc, the current requirement is an error of at most 9 ulps
(units in last place) for all rounding modes. (In some cases this is
16 ulps instead.) Any error larger than that is considered as a bug.
For j0f/y0f/j1f/y1f, the maximal error is millions of ulps for those
functions in GNU libc 2.33 [1]. My patch reduces that maximal error
to 9 ulps.
* there is some discussion in the C standard to reserve names like cr_sin
for correctly rounded functions. I have a project to implement such
functions, and contribute them to any interested mathematical library.
If you are interested in joining that project, please tell me.
Best regards,
Paul
[1] https://members.loria.fr/PZimmermann/papers/accuracy.pdf
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf (7.31.8)
[3] https://members.loria.fr/PZimmermann/papers/coremath.pdf
next prev parent reply other threads:[~2021-02-21 7:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 9:02 Paul Zimmermann
2021-02-19 16:44 ` Michael Morrell
2021-02-19 21:15 ` Joseph Myers
2021-02-21 7:37 ` Paul Zimmermann [this message]
2021-02-23 19:07 ` Michael Morrell
2021-02-23 19:34 ` Joseph Myers
2021-02-24 18:59 ` Adhemerval Zanella
2021-02-25 10:27 ` Paul Zimmermann
2021-02-25 11:24 ` Adhemerval Zanella
2021-02-26 6:40 ` Paul Zimmermann
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=mwa6rxx454.fsf@tomate.loria.fr \
--to=paul.zimmermann@inria.fr \
--cc=libc-alpha@sourceware.org \
--cc=mmorrell@tachyum.com \
/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).