Re: document the fact that "Known Maximum Errors" might not be maximal

[Joseph Myers <josmyers@redhat.com>]

On Fri, 16 Feb 2024, Vincent Lefevre wrote:

> If I understand correctly, the *intent* is to give an error bounded
> by 3 ulp, i.e. an error up to 3 ulp is not something that the user
> should expect to be "fixed".

The intent is that the functions should be both "accurate" (where more 
details of the precise goals are given in the manual - see the first 
several paragraphs of the "Errors in Math Functions" section) and "fast".

3 ulp isn't a specific intent.  The testsuite always treats any error 
above 9 ulp (16 ulp for IBM long double) as a bug.  In practice I think 
it's likely that most or all of the functions with errors above 1 ulp for 
round-to-nearest could be improved (other than for IBM long double) to 
have errors of at most 1 ulp without making them any slower, using better 
implementations.  (The definition of ulp used by the testsuite and the 
table in the manual compares to the correctly rounded result, *not* to the 
mathematically precise result.  So fractional ulp values are not possible, 
except for the special case where the result returned by the function has 
a lower exponent than the correctly rounded result.)

(The main cases that would be genuinely hard to get down to low errors for 
all arguments are the cpow, jn and yn functions.)

-- 
Joseph S. Myers
josmyers@redhat.com