From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 42EF63858C54; Mon, 4 Mar 2024 18:27:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 42EF63858C54 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1709576863; bh=7kaKHfd9aohCFRsXKvqYis9LalaQJDBKy/OkBY7oKa4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GYxNXVaXN1x1h0jFnvPt+8X1sgSrCP8HN4lpxF6xA2zOMpuCB92O8Rcuobhq3BKix AfnvIXIYcvRMmwO5c6AzteuBRTEIv/q54XqaVQtVDDjpKcI2C4btdZPOoiiCLpk3/r tcDq65eucUgjIagzU3pENlncwPij/2cdDtilqOUQ= From: "wdijkstr at arm dot com" To: glibc-bugs@sourceware.org Subject: [Bug math/28472] pow(10, i) accuracy Date: Mon, 04 Mar 2024 18:27:42 +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: wdijkstr at arm dot com 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 #19 from Wilco --- (In reply to Vincent Lef=C3=A8vre from comment #18) > (In reply to Wilco from comment #17) > > (In reply to Vincent Lef=C3=A8vre from comment #16) > > > (In reply to Wilco from comment #15) > > > > GLIBC double precision pow is the most accurate of all libraries te= sted at > > > > 0.523 ULP [1]. > > >=20 > > > What you forget is that this is the accuracy *tested* on arbitrary va= lues. > > > The actual accuracy may be worse. And this is the case here, with an > > > accuracy larger than 1 ulp, according to the results in Comment #6! > >=20 > > Please see the implementation - it documents the accuracy across the fu= ll > > input ranges. The worst-case reported by random testing is slightly low= er > > due to not being able to test all input values. >=20 > OK, this is something that is new to me. So perhaps [1] should also docum= ent > the proved error bounds. That might be too much work to figure out for every math library (AFAIK only GLIBC documents these error bounds in the implementations). Note the final result vary depending on FMA support, evaluation order etc. > > Ie. if we have an algorithm that does < 0.55ULP before rounding, we can= 't ever > get a 2 ULP error. >=20 > OK, but in addition to the source, such proved error bounds (assuming no > mistakes in the analysis) should be given in the glibc manual. >=20 > Also, note that an error < 0.55 ULP before rounding does not guarantee th= at > pow(2,i) will be correct for the integers i. So, perhaps more should be s= aid. As it happens, it does work out perfectly for pow(2, i) and exp2(i). Only e= xp10 and pow(10, i) have a few cases that are not: exp10(126): 0x1.7a2ecc414a04p+418 0x1.7a2ecc414a03f7ff6ca1cb527788p+418 pow(10, 23): 0x1.52d02c7e14af7p+76 0x1.52d02c7e14af68p+76=20 pow(10, 210): 0x1.8557f31326bbcp+697 0x1.8557f31326bbb7fcd59ff127a01dp+697= =20 These are very close to the halfway rounding point and would need an extra = 16 bits internal precision to get right. pow(10, 23) is exactly on the mid-poi= nt, so is even harder. Note GLIBC previously had some correctly rounded math functions, but they w= ere a total nightmare. Whenever you got close to a halfway point, performance dropped by a factor of a million times, even for cases that were relatively easy. That's a lesson learnt that we don't ever want to repeat again. --=20 You are receiving this mail because: You are on the CC list for the bug.=