From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11287 invoked from network); 4 Dec 2020 17:21:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Dec 2020 17:21:29 -0000 Received: (qmail 16307 invoked by uid 550); 4 Dec 2020 17:21:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16284 invoked from network); 4 Dec 2020 17:21:24 -0000 Date: Fri, 4 Dec 2020 18:21:12 +0100 From: Szabolcs Nagy To: Paul Zimmermann Cc: musl@lists.openwall.com Message-ID: <20201204172112.GR1370092@port70.net> Mail-Followup-To: Paul Zimmermann , musl@lists.openwall.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] Accuracy of Mathematical Functions in Single, Double, and Quadruple Precision * Paul Zimmermann [2020-12-04 17:37:59 +0100]: > I have published a new version of my note, including results for double and > quadruple precision, and also for bivariate functions (atan2, hypot, pow): > > https://homepages.loria.fr/PZimmermann/papers/#accuracy > > With Musl 1.2.1, the largest error I found in double precision is 14 ulps, > except for the Bessel functions and the lgamma function. bessel functions and lgamma have large errors at least near zeros, and those would be hard to fix and i don't think we care enough to work on them, (but patches are welcome). the generalized bessel functions are also a denial of service attack vector (unlikely to be relevant in practice, but that's a more significant issue than the accuracy at zeros, all other math functions are real-time robust: worst-case computation latency is reasonably bounded, although trig arg reduction code could be improved in this area). tgamma was known to have >5 ulp errors, the code was mainly optimized to be small and simple. exp10 has a simple naive implementation, 4 ulp is not surprising there, we can fix this if needed (but it's a non-standard function). erfc is good old fdlibm code, 3 ulp is ok, but i think it can be fixed if split into more intervals (and likely made faster too if the divisions are avoided and only polynomial approximation is used). the rest is < 3 ulp error and the most important functions are < 1 ulp which looks reasonable to me. > If something changes in future versions, please tell me so that I can revise > my note. ok.