Hi Vincent, On Sun, Mar 03, 2024 at 12:46:00PM +0100, Vincent Lefevre wrote: > On 2024-03-03 03:21:26 +0100, Alejandro Colomar wrote: > > Maybe just add some headers to core-math, and package it as a > > standalone library. > > The issue is that it is not portable yet. Well, one could package it just to the systems to which it is portable, if that's useful. That's why a standalone library has more chances of being available soon than glibc. You'd need to make it portable (and other things) to put it in glibc; but if you say "here's libcore-math, avaiable only in XXX systems", you could get distros to distribute it already. And then provide headers that don't clash with glibc, such as <core-math/*.h> or whatever. > > > > FWIW, it appears that the author of the glibc exp10 implementation > > > agrees with me that the implementation is sub-standard: > > > > > > https://codebrowser.dev/glibc/glibc/math/e_exp10.c.html > > > > > > /* This is a very stupid and inprecise implementation. It'll get > > > replaced sometime (soon?). */ > > > return __ieee754_exp (M_LN10 * arg); > > > > Hmmm. Still, it's simple. If pow(10, x) is strictly better, maybe one > > can prove it and send a patch. Or for something better, it'll take more > > work. > > If by "strictly better", you mean that for each input, it returns a > result that is at least as accurate as the one returned by the above > expression, then, probably no. The reason is that the rounding errors > in the above expression may partly compensate on a random basis. So, > for some proportion of inputs, you'll actually get an accurate result. > And unless pow is designed to be almost correctly rounded, it will > probably be sometimes worse. Then glibc's current code is good, I guess. It's simple, and works for most programs. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> Looking for a remote C programming job at the moment.
Attachment:
signature.asc
Description: PGP signature
