From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sourceware.org (Postfix) with ESMTPS id 8E68A386F022 for ; Fri, 11 Dec 2020 17:02:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8E68A386F022 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Paul.Zimmermann@inria.fr X-IronPort-AV: E=Sophos;i="5.78,411,1599516000"; d="scan'208";a="482532386" Received: from tomate.loria.fr (HELO tomate) ([152.81.10.51]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2020 18:02:47 +0100 Date: Fri, 11 Dec 2020 18:02:47 +0100 Message-Id: From: Paul Zimmermann To: Fabian Schriever Cc: newlib@sourceware.org In-Reply-To: <20201211155735.2645-1-fabian.schriever@gtd-gmbh.de> (message from Fabian Schriever on Fri, 11 Dec 2020 16:57:35 +0100) Subject: Re: [PATCH] Fix error in powf for x close to 1 and large y References: <20201211155735.2645-1-fabian.schriever@gtd-gmbh.de> X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 17:02:50 -0000 Dear Fabian, that was fast! Thank you very much. Paul > From: Fabian Schriever > Date: Fri, 11 Dec 2020 16:57:35 +0100 > > This patch fixes the error found by Paul Zimmermann (see > https://homepages.loria.fr/PZimmermann/papers/#accuracy) regarding x > close to 1 and rather large y (specifically he found the case > powf(0x1.ffffeep-1,-0x1.000002p+27) which returns +Inf instead of the > correct value). We found 2 more values for x which show the same faulty > behaviour, and all 3 are fixed with this patch. We have tested all > combinations for x in [+1.fffdfp-1, +1.00020p+0] and y in > [-1.000007p+27, -1.000002p+27] and [1.000002p+27,1.000007p+27]. > --- > newlib/libm/math/ef_pow.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/newlib/libm/math/ef_pow.c b/newlib/libm/math/ef_pow.c > index e3579f071..07b225f8c 100644 > --- a/newlib/libm/math/ef_pow.c > +++ b/newlib/libm/math/ef_pow.c > @@ -138,7 +138,7 @@ ivln2_l = 7.0526075433e-06; /* 0x36eca570 =1/ln2 tail*/ > /* |y| is huge */ > if(iy>0x4d000000) { /* if |y| > 2**27 */ > /* over/underflow if x is not close to one */ > - if(ix<0x3f7ffff8) return (hy<0)? __math_oflowf(0):__math_uflowf(0); > + if(ix<0x3f7ffff4) return (hy<0)? __math_oflowf(0):__math_uflowf(0); > if(ix>0x3f800007) return (hy>0)? __math_oflowf(0):__math_uflowf(0); > /* now |1-x| is tiny <= 2**-20, suffice to compute > log(x) by x-x^2/2+x^3/3-x^4/4 */ > -- > 2.26.1.windows.1 >