DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60J8sHmN4023012
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F2804BA2E22
Received-SPF: SoftFail (mail3-relais-sop.national.inria.fr:
 domain of Paul.Zimmermann@inria.fr is inclined to not
 designate 152.81.2.78 as permitted sender) identity=mailfrom;
 client-ip=152.81.2.78;
 receiver=mail3-relais-sop.national.inria.fr;
 envelope-from="Paul.Zimmermann@inria.fr";
 x-sender="Paul.Zimmermann@inria.fr"; x-conformance=spf_only;
 x-record-type="v=spf1"; x-record-text="v=spf1
 include:mailout.safebrands.com a:basic-mail.safebrands.com
 a:basic-mail01.safebrands.com a:basic-mail02.safebrands.com
 ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160
 ip4:128.93.162.3 ip4:128.93.162.88 ip4:89.107.174.7 mx ~all"
Received-SPF: None (mail3-relais-sop.national.inria.fr: no sender
 authenticity information available from domain of
 postmaster@araignee) identity=helo; client-ip=152.81.2.78;
 receiver=mail3-relais-sop.national.inria.fr;
 envelope-from="Paul.Zimmermann@inria.fr";
 x-sender="postmaster@araignee"; x-conformance=spf_only
Date: Mon, 19 Jan 2026 09:53:24 +0100
Message-Id: <p9u0ikcyugor.fsf@araignee.loria.fr>
To: cygwin@cygwin.com
In-Reply-To: <3c56778a-870c-4bae-a855-6b96392870c8@SystematicSW.ab.ca>
 (message from Brian Inglis on Sun, 18 Jan 2026 15:43:21 -0700)
Subject: Re: Log2 seems inefficient
References: <226987210.591128.1768766440723@connect.xfinity.com>
 <3c56778a-870c-4bae-a855-6b96392870c8@SystematicSW.ab.ca>
Precedence: list
From: Paul Zimmermann via Cygwin <cygwin@cygwin.com>
Reply-To: Paul Zimmermann <Paul.Zimmermann@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

       Hi,

> With default settings the worst case error in nearest rounding mode is 0.547 ULP 
> with inlined fma and fma contraction.
> It uses a 1 KB lookup table,
> ...
> Note that the math.h header defines log2(x) to be log(x)/Ln2, this is
> not changed, so the new code is only used if that macro is suppressed."
>
> Paul Zimmerman regularly posts library math function comparisons on the newlib 
> and comparable library mailing lists, available at:
> 
> 	https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> that should give you an idea of the current state of the functions, if he is 
> even aware of the issue.

indeed, the known worst case error for Newlib log2 is 2.06 ulp:

log2 0 -1 0x1.68d778f076021p+0 [2] [2.06] 2.05526 2.055255219183752
libm gives 0x1.fb1b88680e7adp-2
mpfr gives 0x1.fb1b88680e7abp-2

The 0.547 value above could match the GNU libc worst error:

log2 0 -1 0x1.1406d79e1b574p+0 [1] [0.548] 0.547538 0.5475371438132311
libm gives 0x1.bd16a11d3404ep-4
mpfr gives 0x1.bd16a11d3404fp-4

If your goal is accuracy, you can try the CORE-MATH implementation:

https://gitlab.inria.fr/core-math/core-math/-/blob/master/src/binary64/log2/log2.c

It takes 19 cycles on average on an Intel(R) Core(TM) i7-8700, and is
correctly rounded (for any rounding mode).

Paul


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple