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 4B4803840C27 for ; Tue, 9 Feb 2021 16:33:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4B4803840C27 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,165,1610406000"; d="scan'208";a="492090180" 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; 09 Feb 2021 17:32:39 +0100 Date: Tue, 09 Feb 2021 17:32:39 +0100 Message-Id: From: Paul Zimmermann To: Wilco Dijkstra Cc: libc-alpha@sourceware.org In-Reply-To: (message from Wilco Dijkstra on Tue, 9 Feb 2021 11:35:18 +0000) Subject: Re: [PATCH 1/4] Add a routine for accurate reduction mod (2pi), for j0f/j1f/y0f/y1f. References: X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, 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: 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, 09 Feb 2021 16:33:09 -0000 Dear Wilco, > Do we really need another range reducer here? Would it be possible to use > the > much faster reduce_fast and reduce_large in > sysdeps/ieee754/flt-32/s_sincosf.h? > Given that returns a 62-bit modulo of PI/4, it should be more accurate as > well. yes indeed I was wondering, and too lazy so far. Your mail forced me to try. reduce_fast is clearly not accurate enough: for x=0x1.96d666p+7, it gives y=0x1.947b0da22168cp+8 (and n=-128), and we clearly see that y is not in [-PI/4,PI/4] as advertized. What happens is that in the #else part of the code that is executed on my machine, r is larger than 2^31, thus the cast (int32_t) r overflows, the value of n is wrong, and thus the returned value x - n * p->hpi. Maybe a comment should be added about this limitation of reduce_fast? As for reduce_large, I need to run again the exhaustive tests for all four functions (j0, j1, y0, y1) and all four rounding modes to see if it is accurate enough. Paul