From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id A7D0D3858D33 for ; Thu, 27 Apr 2023 14:48:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A7D0D3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D27A81FE4D; Thu, 27 Apr 2023 14:48:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1682606883; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Uc8RsPns4+SqoGkZNxGEbKJA61iqpGODlR5OKVasG7Y=; b=QMpiSj6dxsYLMeLy8FPtBZDmjXrdz+YnGlQTWpJHcKwCmPG4CxDf9sPC7+XZqTznS6JB4+ NBDrfZfj+jsx0FxekrlARftR4cy+O4ynVGrqs+O4+H8U8LFlRgIRTxeEiTYX+X1VEo4wWW auuInxslH6jz47Q6ejH3bjaIfQSJCLk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1682606883; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Uc8RsPns4+SqoGkZNxGEbKJA61iqpGODlR5OKVasG7Y=; b=aNTjfT9lrEYFFMaHtc8Y8XUDHdqvk4TGzb0bIgT/aCzVnrJtuiPFUmyv/ugsg0w4K9sm3H HagmH3pdGiEF++AA== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A7C222C141; Thu, 27 Apr 2023 14:48:03 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 5925F6453; Thu, 27 Apr 2023 14:48:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 57F1763D9; Thu, 27 Apr 2023 14:48:03 +0000 (UTC) Date: Thu, 27 Apr 2023 14:48:03 +0000 (UTC) From: Michael Matz To: Jakub Jelinek cc: Aldy Hernandez , Richard Biener , "Joseph S. Myers" , gcc-patches@gcc.gnu.org, Siddhesh Poyarekar , Andrew MacLeod Subject: Re: [PATCH] Add targetm.libm_function_max_error In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, On Thu, 27 Apr 2023, Jakub Jelinek wrote: > The first really large error I see is for sinl with > x/2gx &val > 0x748160ed90d9425b 0xefd8b811d6293294 > i.e. > 1.5926552660973502228303666578452949e+253 > with most significant double being > 1.5926552660973502e+253 > and low double > -5.9963639272208416e+230 Such large numbers will always be a problem with the range reduction step in sin/cos. With double-double the possible mantissage length can be much larger than 106, and the range reduction needs to be precise to at least those many bits to give anything sensible. Realistically I think you can only expect reasonably exact results for double-double on operations that require range-reductions for (a) "smallish" values. Where the low double is (say) <= 2^16 * PI, or (b) where the low double is consecutive to the high double, i.e. the overall mantissa size (including the implicit zeros in the middle) is less than 107 (or whatever the current precision for the range-reduction step on large values is) > given is > -0.4025472157704263326278375983156912 > and expected (mpfr computed) > -0.46994008859023245970759964236618727 > But if I try on x86_64: > #define _GNU_SOURCE > #include > > int > main () > { > _Float128 f, f2, f3, f4; > double d, d2; > f = 1.5926552660973502228303666578452949e+253f128; > d = 1.5926552660973502e+253; > f2 = d; > f2 += -5.9963639272208416e+230; > f3 = sinf128 (f); > f4 = sinf128 (f2); > d2 = sin (d); > return 0; > } > where I think f2 is what matches most closely the 106 bit precision value, > (gdb) p f > $7 = 1.5926552660973502228303666578452949e+253 > (gdb) p f2 > $8 = 1.59265526609735022283036665784527174e+253 > (gdb) p f3 > $9 = -0.277062522218693980443596385112227247 > (gdb) p f4 > $10 = -0.402547215770426332627837598315693221 > and f4 is much closer to the given than to expected. Sure, but that's because f2 is only "close" to the double-double exact value of (1.5926552660973502e+253 + -5.9963639272208416e+230) relatively, not absolutely. As you already wrote the mantissa to represent the exact value (which double-double and mpfr can!) is larger than 106 bits. The necessary error of rounding to represent it in f128 is small in ULPs, but very very large in magnitude. Large magnitude changes of input value to sin/cos essentially put the value into completely different quadrants and positions within those quadrants, and hence the result under such rounding in input can be _wildly_ off. E.g. imagine a double-double representing (2^107 * PI + PI/2) exactly (assume PI is the 53-bit representation of pi, that's why I say "exactly"). The correct result of sin() on that is 1. The result on the nearest f128 input value (2^107 * PI) will be 0. So you really can't compare f128 arithmetic with double-double one when the mantissas are too far away. So, maybe you want to only let your tester test "good" double-double values, i.e. those that can be interpreted as a about-106-bit number where (high-exp - low-exp) <= about 53. (Or just not care about the similarities of cos() on double-double to a random number generator :) ) Ciao, Michael.