From nobody Wed Sep 27 08:57:01 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RwVqC2YQwz4v9gb for ; Wed, 27 Sep 2023 08:57:11 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.inria.fr", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RwVqB0VmPz3RJT for ; Wed, 27 Sep 2023 08:57:09 +0000 (UTC) (envelope-from Paul.Zimmermann@inria.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=inria.fr header.s=dc header.b=VlTKmfyM; spf=pass (mx1.freebsd.org: domain of Paul.Zimmermann@inria.fr designates 192.134.164.104 as permitted sender) smtp.mailfrom=Paul.Zimmermann@inria.fr; dmarc=pass (policy=none) header.from=inria.fr 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=IEpjmkjjLLXFZ5ss0GfYuEd4y828fLckzDdW5eBaLLs=; b=VlTKmfyMQYhDlERGXJVOBtx++6M0ypnTqqvdHrGnm8lQFKACI6AmDT42 7DTAwLuBuI1LeRP9Zeb4Q0DdXNeTniGlZgpJji/NgAx/FQkj0d/NwRM8y 1Y5oVCwJKYmqX5MvDF8hw5I2HF6elN1mNXd50XNRUqg2PJ0Q6WBk9/urw g=; 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 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.03,179,1694728800"; d="scan'208";a="67075713" 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; 27 Sep 2023 10:57:02 +0200 Date: Wed, 27 Sep 2023 10:57:01 +0200 Message-Id: From: Paul Zimmermann To: Alexander Leidinger Cc: sgk@troutmask.apl.washington.edu, freebsd-hackers@freebsd.org In-Reply-To: <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> (message from Alexander Leidinger on Wed, 27 Sep 2023 10:32:18 +0200) Subject: Re: Accuracy of Mathematical Functions References: <1395eeabc6d404997f6a09a7b39d3da5@Leidinger.net> <8849166a6a2deb6ebc1f307d6e8a66a9@Leidinger.net> X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[inria.fr:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[inria.fr,none]; R_DKIM_ALLOW(-0.20)[inria.fr:s=dc]; R_SPF_ALLOW(-0.20)[+ip4:192.134.164.0/24]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[192.134.164.104:from]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[inria.fr:+]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:2200, ipnet:192.134.164.0/24, country:FR] X-Rspamd-Queue-Id: 4RwVqB0VmPz3RJT List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Hi Alexander, > A thought just crossed my mind... should we consider to provide two ABI > compatible math libs, one fast (and "acceptable accurate"... whatever > this means), and one accurate (and this one being the default to link > against)? Users then could use libmap.conf(5) to use the one according > to their needs. this is not the same idea, but the new C standard allows to have two functions exp and cr_exp: See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf, page 454, item 4: Function names that begin with cr_ are potentially reserved identifiers and may be added to the header. The cr_ prefix is intended to indicate a correctly rounded version of the function. Having both under the same name, and having a runtime dispatcher that chooses either the fast version or the correctly rounded version, is a nice idea! Paul