Re: Accuracy of Mathematical Functions

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 09/08/24 05:16, Paul Zimmermann wrote:
>        Dear Joseph,
> 
>> 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.
> 
> in the next update we'll point out that these disastrous results with
> other rounding modes were in the past. Surely results with other rounding modes
> would be interesting, volunteers to implement that are welcome!
> 
> I did a quick test with exp and GNU libc 2.40:
> 
>     -0x1.49f33ad2c1c58p+9,   /* GNU libc 0.510359 */
>     -0x1.9df9aecc00001p-29,  /* GNU libc RNDZ 1.24399 */
>     0x1.50f5a68c91c18p-1,    /* GNU libc RNDU 1.01597 */
>     -0x1.9df9aecc00001p-29,  /* GNU libc RNDD 1.24399 */
> 
>> * 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).
> 
> agreed, maybe "trivial" would be more accurate. By the way, if one wants
> to replace say exp10m1f by a more accurate version, what are the steps to
> follow?

The exp10m1 should be easier because there is no arch-specific implementation.
I think it would be easier as add a sysdeps/ieee754/flt-32/s_exp10m1.c
one with the same semantics as the template one.  I can help you out if need.

> 
>> * 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.
> 
> we also got similar feedback for complex functions. Indeed I believe one might
> have surprises, even for basic operations since there is no standard. But
> again, time is limited, and volunteers are welcome! (This might be a different
> document, testing less libraries, and updated less often.)
> 
> Paul