From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id BAEAC3851C27 for ; Sun, 21 Feb 2021 07:37:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BAEAC3851C27 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.81,194,1610406000"; d="scan'208";a="373669209" Received: from tomate.loria.fr (HELO tomate) ([152.81.10.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2021 08:37:43 +0100 Date: Sun, 21 Feb 2021 08:37:43 +0100 Message-Id: From: Paul Zimmermann To: Michael Morrell Cc: libc-alpha@sourceware.org In-Reply-To: <6cf8704bcd9a45ac82cf23f05aab68a6@tachyum.com> (message from Michael Morrell on Fri, 19 Feb 2021 16:44:02 +0000) Subject: Re: Fix the inaccuracy of j0f/y0f/j1f/y1f References: <6cf8704bcd9a45ac82cf23f05aab68a6@tachyum.com> X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2021 07:37:46 -0000 Dear Michael, > I'm curious about something. Where is it specified what the required accuracy is for a given math function? Before I discovered the libm-test-ulps file, I would have expected a C library to be required to computed the exact result for any defined function (possibly allowing some inaccuracy if -ffast-math were specified). I look through the POSIX spec, but couldn't find any place that mentioned an accuracy requirement. to complete Joseph's answer: * the IEEE 754 standard (even in its latest revision from 2019) does not require "correct rounding" for the mathematical functions (except for sqrt). More precisely it defines "Additional mathematical operations" which shall return correctly rounded results, but these operations are not mandatory. This means that mathematical libraries can do whatever they want, and in practice they do [1]. * for GNU libc, the current requirement is an error of at most 9 ulps (units in last place) for all rounding modes. (In some cases this is 16 ulps instead.) Any error larger than that is considered as a bug. For j0f/y0f/j1f/y1f, the maximal error is millions of ulps for those functions in GNU libc 2.33 [1]. My patch reduces that maximal error to 9 ulps. * there is some discussion in the C standard to reserve names like cr_sin for correctly rounded functions. I have a project to implement such functions, and contribute them to any interested mathematical library. If you are interested in joining that project, please tell me. Best regards, Paul [1] https://members.loria.fr/PZimmermann/papers/accuracy.pdf [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf (7.31.8) [3] https://members.loria.fr/PZimmermann/papers/coremath.pdf