Re: [PATCH 0/3] Fix powf inaccuracies up to ~169 ULP reported by Paul Zimmermann

On 2024-09-11 08:58, Paul Zimmermann wrote:
> thank you Fabian for the update.
> 
> Now I find a maximal error < 1 ulp for powf:
> 
> Checking pow with newlib-4.4.0.20231231-patched
> pow 0 -1 0x1.d6411cp-102,0x1.793482p+0 [1.00] 1 0.9999999735288204
> 
> By the way I noticed that Newlib does not honor the current rounding mode in printf:
> 
> $ cat test_printf.c
> #include <stdio.h>
> #include <fenv.h>
> 
> int main()
> {
>    double x = 0.9694811147877118;
>    fesetround (FE_UPWARD);
>    printf ("x=%.16f upward:%.6g\n", x, x);
> }
> 
> $ gcc test_printf.c -lm
> $ ./a.out
> x=0.9694811147877119 upward:0.969482
> 
> $ gcc test_printf.c /localdisk/zimmerma/newlib-4.4.0.20231231/build/x86_64/newlib/libm.a
> $ ./a.out
> x=0.9694811147877118 upward:0.969481
> 
> Is that a known issue?

Is that not only a requirement of IEEE arithmetic operations?
Is that also an expected requirement of *printf?

As with glibc, newlib printf only says it rounds output:

https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/sprintf.c#l448

Newlib printf uses DMG dtoa based on Steele & White to produce correctly rounded 
output:

https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/dtoa.c

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry