public inbox for
 help / color / mirror / Atom feed
From: Joseph Myers <>
To: Jakub Jelinek <>
Cc: Aldy Hernandez <>,
	GCC patches <>,
	Andrew MacLeod <>
Subject: Re: [PATCH] [range-ops] Implement sqrt.
Date: Mon, 14 Nov 2022 21:55:29 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <Y3FV51Pds4bllqvD@tucnak>

On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote:

> So, I wonder if we don't need to add a target hook where targets will be
> able to provide upper bound on error for floating point functions for
> different floating point modes and some way to signal unknown accuracy/can't
> be trusted, in which case we would give up or return just the range for

Note that the figures given in the glibc manual are purely empirical 
(largest errors observed for inputs in the glibc testsuite on a system 
that was then used to update the libm-test-ulps files); they don't 
constitute any kind of guarantee about either the current implementation 
or the API, nor are they formally verified, nor do they come from 
exhaustive testing (though worst cases from exhaustive testing for float 
may have been added to the glibc testsuite in some cases).  (I think the 
only functions known to give huge errors for some inputs, outside of any 
IBM long double issues, are the Bessel functions and cpow functions.  But 
even if other functions don't have huge errors, and some 
architecture-specific implementations might have issues, there are 
certainly some cases where errors can exceed the 9ulp threshold on what 
the libm tests will accept in libm-test-ulps files, which are thus 
considered glibc bugs.  (That's 9ulp from the correctly rounded value, 
computed in ulp of that value.  For IBM long double it's 16ulp instead, 
treating the format as having a fixed 106 bits of precision.  Both figures 
are empirical ones chosen based on what bounds sufficed for most libm 
functions some years ago; ideally, with better implementations of some 
functions we could probably bring those numbers down.))

Joseph S. Myers

  parent reply	other threads:[~2022-11-14 21:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-13 20:05 Aldy Hernandez
2022-11-13 20:39 ` Jakub Jelinek
2022-11-14  7:45   ` Aldy Hernandez
2022-11-14 14:30     ` Jeff Law
2022-11-14 14:35       ` Jakub Jelinek
2022-11-14 14:48         ` Jeff Law
2022-11-14 15:01         ` Aldy Hernandez
2022-11-14 21:55   ` Joseph Myers [this message]
2022-11-16 20:32     ` Jakub Jelinek
2022-11-17 16:40       ` Aldy Hernandez
2022-11-17 16:48         ` Aldy Hernandez
2022-11-17 17:42           ` Aldy Hernandez
2022-11-17 18:59         ` Joseph Myers
2022-11-17 19:37           ` Jakub Jelinek
2022-11-17 20:43             ` Joseph Myers
2022-11-18  8:39             ` Richard Biener
2022-11-18 10:37               ` Aldy Hernandez
2022-11-18 10:44                 ` Jakub Jelinek
2022-11-18 11:20                   ` Aldy Hernandez
2022-11-18 11:57                     ` Aldy Hernandez
2022-11-18 12:14                   ` Richard Biener

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:

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

  git send-email \ \ \ \ \ \ \

* 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).