Re: Man page issues: logb, significand, cbrt, log2, log10, exp10

From: Alejandro Colomar <alx@kernel.org>
To: Vincent Lefevre <vincent@vinc17.net>,
	Morten Welinder <mwelinder@gmail.com>,
	linux-man@vger.kernel.org, libc-alpha@sourceware.org,
	jsm-csl@polyomino.org.uk, newbie-02@gmx.de
Subject: Re: Man page issues: logb, significand, cbrt, log2, log10, exp10
Date: Sun, 3 Mar 2024 13:21:25 +0100	[thread overview]
Message-ID: <ZeRrRgEvvxjvHi-K@debian> (raw)
In-Reply-To: <20240303114600.GA3653@qaa.vinc17.org>

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]