[CC += glibc, and those involved in the glibc bug report]

Hi Morten,

On Sat, Mar 02, 2024 at 04:17:36PM -0500, Morten Welinder wrote:
> I think what happens is that the compiler (not glibc) computes that
> exp10 for you and that the compiler happens to be more accurate.
> Here's what I get for the loop:
> 
>   for (int i = 1; i < 20; i++) {
>     printf ("%.20g\n", exp10 (i));
>   }
> 
> welinder@CarbonX1:~$ ./a.out
> 10
> 100
> 1000.0000000000001137
> 10000.000000000001819
> 100000
> 1000000
> 9999999.9999999981374
> 99999999.999999985099
> 999999999.99999988079
> 10000000000
> 100000000000
> 1000000000000
> 10000000000000
> 100000000000000
> 1000000000000000
> 10000000000000000
> 99999999999999984
> 1000000000000000000
> 10000000000000000000
> 
> Here's the bug report to go with this:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28472
> Note comment 6.  It is clearly not a high-priority item for glibc.

Thanks for that link.

I agree with glibc that the standard specifies that these functions need
not be precise.  That lost precission probably results in better
performance.  Most programs won't care that these functions are
inaccurate.

If you need a correctly-rounded version of these functions, which is
perfectly reasonable, the right thing to ask is that libc implements
the cr_ version of these functions.

I also understand that adding functions to glibc isn't straightforward,
so glibc maintainers have reasons to not do it at the moment.  In fact,
lately I've been leaning towards thinking that libc is a huge monster to
which nothing more should be added, at all.

How about writing a new library --maybe call it libm-cr, maybe
libm-cr-pow, maybe libm-cr-exp10, depending on how extensive you want
it-- and add cr_exp10(3) to that library?  You could do that, and just
support the systems you need to support.  The effort would be certainly
smaller than adding the function to glibc.

Regarding the manual pages, I don't remember from the top of my head if
there's any page documenting that libm functions are imprecise.  I would
prefer documenting it in one place, rather than adding caveats to every
libm page.

> 
> M.

Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.