From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BF40F3858D28; Mon, 4 Mar 2024 19:23:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF40F3858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1709580208; bh=nqMy3wfL3xSTfv1vx84PHpOkVPQtciYrTeHQCjzK8y4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ORqMeMko6uyWdTKJUo0dlseY5fXDh6bd1TgR/I7FGtPRvIzA/4QDO2/OjYhJa31Fl QRALq2Eu7u27ZSJjDfqVF3u+cm5Y7OtvNU3dnSf+OPJWX30bGNaAzB9ZyQA/wAL3BF sxRjki6xrhz3HAFxK/sK2o8eY4DxcE4nXh+zQoUY= From: "vincent-srcware at vinc17 dot net" To: glibc-bugs@sourceware.org Subject: [Bug math/28472] pow(10, i) accuracy Date: Mon, 04 Mar 2024 19:23:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: math X-Bugzilla-Version: 2.31 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vincent-srcware at vinc17 dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28472 --- Comment #20 from Vincent Lef=C3=A8vre --- (In reply to Wilco from comment #19) > (In reply to Vincent Lef=C3=A8vre from comment #18) > > OK, this is something that is new to me. So perhaps [1] should also doc= ument > > the proved error bounds. >=20 > That might be too much work to figure out for every math library (AFAIK o= nly > GLIBC documents these error bounds in the implementations). Note the final > result vary depending on FMA support, evaluation order etc. Well, I meant only when the bound is known. > As it happens, it does work out perfectly for pow(2, i) and exp2(i). Only > exp10 and pow(10, i) have a few cases that are not: >=20 > exp10(126): 0x1.7a2ecc414a04p+418 0x1.7a2ecc414a03f7ff6ca1cb527788p+418 I meant only for the exact cases (pow(2,i) is always exact for integer i, except in case of overflow/underflow, of course). exp10(i) is exact for integers i up to 22 (5^22 < 2^53 < 5^23), but these a= re not powers of 2. You need to be careful with powers of 2, because this is w= here the value of the ulp changes (I've seen errors in several proofs because of that); such cases may need a separate check. > Note GLIBC previously had some correctly rounded math functions, but they > were a total nightmare. Whenever you got close to a halfway point, > performance dropped by a factor of a million times, even for cases that w= ere > relatively easy. The implementation was much too pessimistic about the probability of failure for the slow path, which used a precision of 768 bits (much more than what = is assumed for cryptographic hashes, for instance). Moreover, some slow cases = (for pow) were inputs that could easily be found in practice. CORE-MATH should b= e a huge improvement. --=20 You are receiving this mail because: You are on the CC list for the bug.=