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 66F06393D025 for ; Tue, 1 Dec 2020 10:29:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 66F06393D025 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,384,1599516000"; d="scan'208";a="366177021" 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; 01 Dec 2020 11:29:10 +0100 Date: Tue, 01 Dec 2020 11:29:10 +0100 Message-Id: From: Paul Zimmermann To: Joseph Myers Cc: libc-alpha@sourceware.org In-Reply-To: (message from Joseph Myers on Mon, 30 Nov 2020 22:21:24 +0000) Subject: Re: [PATCH] add inputs to auto-libm-test-in yielding larger errors References: X-Spam-Status: No, score=-4.1 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: Tue, 01 Dec 2020 10:29:44 -0000 Dear Joseph, > Date: Mon, 30 Nov 2020 22:21:24 +0000 > From: Joseph Myers > > On Mon, 30 Nov 2020, Paul Zimmermann wrote: > > > Dear Joseph, > > > > submitted as https://sourceware.org/bugzilla/show_bug.cgi?id=26982, and a > > similar one for tgamma (https://sourceware.org/bugzilla/show_bug.cgi?id=26983). > > Thanks. It would be interesting to know if similar cases can be found for > other floating-point formats (inputs with large errors for different > formats could go in the same bugs rather than needing a separate bug for > each format) as that might affect how many implementations need to get > similar fixes. You've done exhaustive searches for float. But have you > looked for such large errors for these functions for ldbl-96 (x86 extended > precision) or ldbl-128 (binary128), for example? (Or for ldbl-128ibm, > with the larger threshold of permitted errors there and the definition of > ulps that treats it like a format with exactly 106 bits of precision.) so far I plan to look for large errors for binary32, binary64 and binary128, for the 6 following libraries: glibc, Intel Math Library, AMD Libm, Redhat newlib, OpenLibm and Musl (as far as I know only glibc and the Intel Math Library do support binary128), on x86_64. I also plan to deal with bivariate functions (pow, atan2, hypot). I will publish the largest errors found (with corresponding inputs), as I already did for binary32. For other formats, it should be easy to adapt my search program. If someone is interested to help with ldbl-96 or ldbl-128ibm, please tell me and I will send you my program. Paul