From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6E3103858C50; Mon, 4 Mar 2024 17:09:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E3103858C50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1709572192; bh=jXRheYnPf0x11fnI7ijLOc51rwPwbCRnGxGxQlMKe0Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IZsUNob9ZJ9G1DSfbs2hAA7+xH0ycrNiV3wv6udFM9+wkVoRN+kAkVK5xDKTXLWXG crkLkz1y/i4SlI1srBZg3m26SDLgKP2cP+IrKJNligKuUysp4yUto/1kiCpvl+VLC8 eTJkt2RCQFZ/fykmb1JtIgiWqSnqrDEZgxSU3Qbw= 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 17:09:51 +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 #18 from Vincent Lef=C3=A8vre --- (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 test= ed at > > > 0.523 ULP [1]. > >=20 > > What you forget is that this is the accuracy *tested* on arbitrary valu= es. > > 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 full > input ranges. The worst-case reported by random testing is slightly lower > due to not being able to test all input values. OK, this is something that is new to me. So perhaps [1] should also document the proved error bounds. > And comment #6 discusses exp10, which had a known ULP of 2.01 in previous > GLIBCs. Sorry, I got confused by a recent mail (2024-03-02) giving these values and saying that this was the corresponding bug report, but this bug is really a= bout pow() according to its title. > Ie. if we have an algorithm that does < 0.55ULP before rounding, we can't= ever > get a 2 ULP error. OK, but in addition to the source, such proved error bounds (assuming no mistakes in the analysis) should be given in the glibc manual. Also, note that an error < 0.55 ULP before rounding does not guarantee that pow(2,i) will be correct for the integers i. So, perhaps more should be sai= d. --=20 You are receiving this mail because: You are on the CC list for the bug.=