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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 22520 invoked from network); 4 Jan 2022 14:20:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Jan 2022 14:20:03 -0000 Received: (qmail 15800 invoked by uid 550); 4 Jan 2022 14:20:01 -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 15768 invoked from network); 4 Jan 2022 14:20:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:message-id:from:to:cc:in-reply-to:subject: references; bh=t5t8wdihFKCoBbRoKFWl3DKGPo5VUNBp4JmPz+b3aBs=; b=rzErKuKsOtqxVYBtOA8Q7MX+u7vvbDMqZffz4246OoSJgI36eTfq8nRX efIuvZ1we2StpzUSdRW0AvFzTWD9oT/mNN/R5y++GGfphFQfHQz1OUyVN BC92zHJH9IKt/Hczx+0aujArNuDyeFxq3EfcUmvhgQdgkFembhUzxLLPb I=; IronPort-Data: =?us-ascii?q?A9a23=3AqVOxFaLWjNkrywnoFE+RKpclxSXFcZb7ZxGrkP8?= =?us-ascii?q?bfHC61Dgr1TJTmDQdD2DXOfyMZDfzKNl2Ptzkp0gHvZCGmoNqS1BcGVNFHysb8?= =?us-ascii?q?5KdbTi6Bh6tZH3KdpWroHqKXqzyU/GYRCwPZiKa9kfF3oTJ9yEmj/nRHuakUoY?= =?us-ascii?q?oBwgqLeNaYHZ44f5cs75h6mJYqYDR7zKl4bsekeWHULOW82Ic3lYv1k62gEgHU?= =?us-ascii?q?MIeF98vlgdWifhj5DcynpSOZX4VDfnZw3DQGuG4EgMmLtsvwo1V/kuBl/ssIs+?= =?us-ascii?q?il7/nfyXmQJaLYFLI2iMQAvDk30EqSi8ai87XMNIkYFpTzQeImtV80tBEs5qYS?= =?us-ascii?q?AEzP6SKlv51vxxwSnwvbfQco9crJlD666R/1XbuUXblxbBLDUo2MIle3/tzBWx?= =?us-ascii?q?U3fEeM3UJfxeFweysqJqwSvNtndgkNMmtOIoCpnx65TrZF/c9XZfbQ+DO7MJE0?= =?us-ascii?q?S12gdpBdd7FZsAYZRJychXLJRZGUn8SFYk6tOOpnWXkNTpApVSKrK4zpWPUyWR?= =?us-ascii?q?Z3LHpMdPOUtiLT84TmVyXzl8qVUyR7goyKNuawCaItHarnO7G2y3hML/+3YaQr?= =?us-ascii?q?pZC6GB/DERJYPHOaWaGnA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AttHtMqjbjrvu+M9fSWTbZOAGYHBQXwd13DAb?= =?us-ascii?q?v31ZSRFFG/FwyPrCoB1L73XJYWgqM03IwerwRJVoMkmsiqKdgLNhT4tKOTOLhI?= =?us-ascii?q?LGFvAZ0WKP+UyGJ8SczJ8p6U4DSdkCNDSYNzET4qiKg3jbYrNQpOVr6JrJuQ63?= =?us-ascii?q?9QYYcegAUdAY0+4NMHfhLqQAfng/OXNWLuv72iNynUvWRZ1bVLX7OlA1G8z44/?= =?us-ascii?q?HbnpPvZhALQzYh9Qm1lDutrIX3FhCJty1uHw+mld0ZkFTtokjc3OGOovu7whjT?= =?us-ascii?q?2yv49JJNgubszdNFGYilltUVAi+EsHfvWK1RH5m5+BwlquCm71gn1PPWpQ07As?= =?us-ascii?q?h143TNOkmovBrW3RX62jpG0Q6k9bahuwq7nSXFfkN+NyMBv/MaTvLh0TtigDio?= =?us-ascii?q?6tMO44qb36AnQC8o0h6Nv+QgHCsa6HZcmkBS2NL7uUYvG7f2WIUh27D3tHklYa?= =?us-ascii?q?voIxiKoLzPMNMeQ/00t8wmP29zURjizyJSKZqXLzQONwbDSkAf/sOSyDJbkW19?= =?us-ascii?q?1SIjtb8id1k7heIAd6U=3D?= X-IronPort-AV: E=Sophos;i="5.88,261,1635199200"; d="scan'208";a="1598123" Date: Tue, 04 Jan 2022 15:19:48 +0100 Message-Id: From: Paul Zimmermann To: Rich Felker Cc: musl@lists.openwall.com, sibid@uvic.ca, christoph.lauter@christoph-lauter.org, Jean-Michel.Muller@ENS-LYON.FR In-Reply-To: <20220104022905.GB7074@brightrain.aerifal.cx> (message from Rich Felker on Mon, 3 Jan 2022 21:29:05 -0500) References: <20220104022905.GB7074@brightrain.aerifal.cx> Subject: Re: [musl] correctly rounded mathematical functions Hi Rich, > License: should be licensed under something permissive and > MIT-compatible, preferably explicitly MIT if you'll be > dual-/multi-licensing anyway. ok, we'll consider multi-licensing with MIT. > Table size: main consideration is that tables need to be pure > shareable rodata, so no runtime generation of contents or pointers in > contents. Failure to follow this would produce significant cost in > *all processes* even ones that don't use the cr_* functions. I would > hope they'd also fit in a few tens of kB of rodata, but I don't know > how realistic that is. tables so far are "static const" > Allowed operations: I'm not sure what the scope of this question is. > Are you asking if things like changing rounding mode would be okay? Or > something else. musl implements C11 and hopefully future versions of > the language library, but is implemented in C99 (+ very minimal set of > common/"GNU C" extensions), so code to be included in musl shouldn't > depend on new language features or compiler extensions not already > used (at least without checking on them first). We also have > softfloat-only targets and targets with excess precision, so code > should be compatible with those (which means not depending on changing > fenv; see commit 4f3d346bffdf9ed2b1803653643dc31242490944 for an > example of where this came up). we avoid playing with fesetround/fegetround since in general this makes the code slower > > We have started to work on two functions (cbrt and acos), for which we > > provide presumably correctly rounded implementations (up to the knowledge > > of hard-to-round cases) [2]. > > > > Christoph Lauter > > Jean-Michel Muller > > Alexei Sibidanov > > Paul Zimmermann > > > > [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf > > [2] https://homepages.loria.fr/PZimmermann/CORE-MATH/ > > Is there a standalone version of the code where it can be read in full > not as a patch to glibc? Is the code being developed in such a way > that it's not potentially a derivative work of the glibc versions? yes there are several standalone versions of the code (entries marked "full" on https://homepages.loria.fr/PZimmermann/CORE-MATH/). Best regards, Paul