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 1E16F3858285 for ; Fri, 16 Feb 2024 10:54:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1E16F3858285 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=inria.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1E16F3858285 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.134.164.104 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708080847; cv=none; b=tQVKRh2jhV0KgzH5xXTJCBAinFPGLa7cMK7mBqk4Ma/gFvC1g6F6c3nzL9on1AL+lM3JUPvUl4utiAa0B8zc1Uo0nXmxCR+9Gb/klZta1kIndUYc/SF1C78CYrqWIeAAuOYSRQSNWVzWJsYdg+VW5/tSg96i6baDV01CIk0UrqA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708080847; c=relaxed/simple; bh=KMB8O9uJ4zXWFQ3L7pJsRp7Vv/BLg85lGE+6NvfZARA=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=PFn6lP26eJwhQDUf2IHrIGVakgdzo+Z1rjjOpl6Wv52mE6pPY2LrhmArbn1hHxRSZrkGqt9l54kQ5xmUo+iV9o2a282TMJ9YHSPySwUiuOpd/byiTVdWfI95OvQjkQ409gpxqXHJBuEYS7SFJZzLxK0b71K34obg/CV276tzoMg= ARC-Authentication-Results: i=1; server2.sourceware.org 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=ry4EuWShKsV0+jSCAumWvFw4TvaDjH29rv8vGigsJc4=; b=Z8OqtpUNjCgyfDvnFbgsdRU7sw4MbtnONT1Wxn80XHsMlL3j7w8ODdpr 9TDt9jlGdxfO/WhdRCIeNfR8JEHitGnmrJT6M/qtd+Res59ZT1qeROqKh jGtEN55hGPZ8kLTD1P+PKFiEj/n36N1KSCw45UyjmhsoWvhX9t+Q16fte Y=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=Paul.Zimmermann@inria.fr; spf=None smtp.helo=postmaster@coriandre Received-SPF: SoftFail (mail3-relais-sop.national.inria.fr: domain of Paul.Zimmermann@inria.fr is inclined to not designate 152.81.9.227 as permitted sender) identity=mailfrom; client-ip=152.81.9.227; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="Paul.Zimmermann@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 include:mailout.safebrands.com a:basic-mail.safebrands.com a:basic-mail01.safebrands.com a:basic-mail02.safebrands.com ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail3-relais-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@coriandre) identity=helo; client-ip=152.81.9.227; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="postmaster@coriandre"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="6.06,164,1705359600"; d="scan'208";a="79824462" Received: from coriandre.loria.fr (HELO coriandre) ([152.81.9.227]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2024 11:54:04 +0100 Date: Fri, 16 Feb 2024 11:54:03 +0100 Message-Id: From: Paul Zimmermann To: Vincent Lefevre Cc: libc-alpha@sourceware.org In-Reply-To: <20240216102258.GB3653@qaa.vinc17.org> (message from Vincent Lefevre on Fri, 16 Feb 2024 11:22:58 +0100) Subject: Re: document the fact that "Known Maximum Errors" might not be maximal References: <20240216094334.GA3653@qaa.vinc17.org> <20240216102258.GB3653@qaa.vinc17.org> X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Vincent, > If I understand correctly, Carlos means (unintended) bugs, in which > case, values may even be completely wrong (as already seen). I think > that saying "documented elsewhere" is misleading. And note that bugs > are not specific to the math functions. Any buggy library function > will not behave as described in the manual. You should rather say > that the given bounds obviously do not take bugs into account, if > you think that this is worth recalling. of course *unknown* bugs might exist, but we are speaking of *known* defects here. The issue is that the manual says "*Known* Maximum Errors in Math Functions". What do you suggest to avoid users deducing from the manual that the ulp error on say y0 is bounded by 3 ulps on x86_64, whereas it can be as large as 5.93e15 ulps? Checking y0 with glibc-2.39/build and rndn GNU libc version: 2.39 GNU libc release: stable y0 0 -1 0x1.c982eb8d417eap-1 [5920543797734652] [5.93e+15] 5.92055e+15 5920543797734652 libm gives -0x1.8p-55 mpfr gives -0x1.af74bfa0f1304p-56 Paul