Re: [PATCH] [range-ops] Implement sqrt.

[Joseph Myers <joseph@codesourcery.com>]

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
> VARYING.

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
joseph@codesourcery.com