From: Joseph Myers <josmyers@redhat.com>
To: Paul Zimmermann <Paul.Zimmermann@inria.fr>
Cc: libc-alpha@sourceware.org, vincenzo.innocente@cern.ch,
riemannic@gmail.com, johnmather@sidefx.com
Subject: Re: Accuracy of Mathematical Functions
Date: Thu, 8 Aug 2024 16:35:46 +0000 (UTC) [thread overview]
Message-ID: <369d3b9-85f7-8f37-26c1-c8c8a6fa447a@redhat.com> (raw)
In-Reply-To: <p9u0sevg1uvn.fsf@coriandre.loria.fr>
On Wed, 7 Aug 2024, Paul Zimmermann wrote:
> Dear Joseph,
>
> > > we have updated our comparison:
> > >
> > > https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> > >
> > > This update is for GNU libc 2.40:
> > >
> > > * it includes the new functions exp10m1, exp2m1, log10p1, log2p1
> > > added in 2.40 (for all formats)
> >
> > The table for single precision only has exp10m1, not the other three
> > functions.
>
> sorry, I have fixed that in a new version (same link).
Thanks. Some further comments on the document (some of which I may have
made before):
* The bug referenced as a reason for not testing other rounding modes was
fixed long ago, results in other rounding modes would be interesting as
well (they would of course make the document longer), and worst-case
inputs for other rounding modes would be worth adding to the glibc tests.
* I don't think "dummy implementations" is a useful description for
implementations that do actually implement the function (within a few
ulp). There are many possible ways to implement a function, including
building on other functions, and those ones are optimized for getting the
APIs into glibc for all supported formats rather than for speed or
accuracy (and replacing by faster, more accurate implementations for
particular formats is welcome).
* As previously mentioned, I still think it would be of interest to see
such data for complex functions (a function with one complex argument and
a complex result is effectively two bivariate real functions.
--
Joseph S. Myers
josmyers@redhat.com
next prev parent reply other threads:[~2024-08-08 16:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 12:24 Paul Zimmermann
2024-08-06 15:27 ` Joseph Myers
2024-08-07 10:37 ` Paul Zimmermann
2024-08-08 16:35 ` Joseph Myers [this message]
2024-08-09 8:16 ` Paul Zimmermann
2024-08-09 12:54 ` Adhemerval Zanella Netto
2024-08-09 15:57 ` Joseph Myers
-- strict thread matches above, loose matches on Subject: below --
2024-02-15 14:47 Paul Zimmermann
2023-09-21 7:11 Paul Zimmermann
2023-02-14 8:05 Paul Zimmermann
2022-08-29 10:41 Paul Zimmermann
2022-02-11 8:22 Paul Zimmermann
2022-02-11 18:23 ` Joseph Myers
2022-02-12 6:39 ` Paul Zimmermann
2022-02-15 1:52 ` Joseph Myers
2021-09-07 14:45 Paul Zimmermann
2021-02-05 10:35 accuracy of mathematical functions 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=369d3b9-85f7-8f37-26c1-c8c8a6fa447a@redhat.com \
--to=josmyers@redhat.com \
--cc=Paul.Zimmermann@inria.fr \
--cc=johnmather@sidefx.com \
--cc=libc-alpha@sourceware.org \
--cc=riemannic@gmail.com \
--cc=vincenzo.innocente@cern.ch \
/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).