From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7799 invoked from network); 6 Sep 2022 23:41:06 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 Sep 2022 23:41:06 -0000 Received: (qmail 15583 invoked by uid 550); 6 Sep 2022 23:41:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15536 invoked from network); 6 Sep 2022 23:41:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=7r48TWHiQCEW2z0mckzZf8KVhnFh6djhDcGOiEc6wDE=; b=BKfUvG4uw8XaiMUTY1no+EiTTIxbXElgFFmKFU5iFSVQvvaykBUZk69BBbDEwxwmmO jri8XwNFu4fUtobwAT0htB70AiSGNkjDKz/IqghEvGJgyyFQogptXVZC9iZF0IhwZKfg T7tQSbC995sLHizGZppASQH/DZrCHJCHO8YxsVFvhj6uVZbhxfdf1ezvqvJIqArSxOGh vmdt06/2knMwlK3T6ke9iHNuCtZlLhrZk8ltGOQqsEXr4RS8ZEzM7pQJCrs6Kqs7KIFY NDKV5wfvDNl5f3e3j0Fu3M+AcbdMQnNyA8bBfmpKOzIEEzn1r68fHM7VwYAc+dZVDyEm DGDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=7r48TWHiQCEW2z0mckzZf8KVhnFh6djhDcGOiEc6wDE=; b=GzSM0jdflEi9dcXSy9qmPWyEfj+Zgb7hI6s231bN1Y0VDPWX51axffM8CLcQp+Dg1f auoMkitusBYSIq+AnWLppxrU01cvBhPfNlJHYMQ9zgLVtB7B9pystVYptEvDjLGjpXTF qv2EL3aBRODODg0MP02u8B3EhnwJmwrP8nSBMJ0K/UpRGJaJFsl+OjU7imZ2PrY0ZenC jMb+9+pB3OA61cD4OvM/RxMLJmqA1rhj6x4n1E9a2L7Q/Zaz04cq2TaQvJM+Oq/GS5cZ cRbtpUgvWydcU/iXer4lJKPNTZwaVTJLIE1hVrCNqjpIVs0Xk1JpMEplFHFK7jaLQ1PT WoyA== X-Gm-Message-State: ACgBeo1HCIy7qvw6/UmvLL+Z7yXZKiQQOT2FhGN+1wfMxPRMInhn4aHx eKQO5c2QDUR81MLOOq2FvFz0SrtEN99Rh+n2AflmEQZbrhU= X-Google-Smtp-Source: AA6agR48da5X/XjQDbWiy3+A6IfMFLgkhdsAw7XWrj1ir3bpMnad3Fy5QxhQG9zutSXk6ZiE5FUuBd/hwGIyRofN7uI= X-Received: by 2002:a05:6512:228b:b0:492:e30d:7e41 with SMTP id f11-20020a056512228b00b00492e30d7e41mr234220lfu.645.1662507650834; Tue, 06 Sep 2022 16:40:50 -0700 (PDT) MIME-Version: 1.0 References: <20220902121755.GS7074@brightrain.aerifal.cx> In-Reply-To: From: enh Date: Tue, 6 Sep 2022 16:40:39 -0700 Message-ID: To: musl@lists.openwall.com Cc: Rich Felker Content-Type: multipart/alternative; boundary="000000000000f78fc205e80ab969" Subject: Re: [musl] Re: integration of CORE-MATH routines into Musl? --000000000000f78fc205e80ab969 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 5, 2022 at 2:09 AM Paul Zimmermann wrote: > Dear Rich, > > > Could you summaraize briefly what you have in mind, and what tradeoffs > > might be? Are these intended to be drop-in replacements for the > > existing standard functions, or implementations for the "cr" versions > > thereof? I have not followed closely the "mandatory requirement of > > correct rounding for mathematical functions in the next revision of > > the IEEE-754 standard" topic and how it relates to the future of C, > > but my vague recollection was that the direction folks were leaning > > was towards a separate set of cr*() functions or something. > > the current situation is: > > - IEEE 754 does not require correct rounding for mathematical functions > > - indeed, the C2X standard will reserve cr_xxx names for correctly rounded > functions > > - thus mathematical libraries will have essentially 3 choices: > > 0) either provide incorrectly rounded functions as (say) exp. > This is the current situation. > > 1) provide incorrectly rounded functions as exp, and correctly rounded > functions as cr_exp. > > 2) or provide only exp, with correct rounding (then cr_exp could be an > alias > for exp) > > It seems that LLVM-libc will go for 2), I have no news from other > libraries. > (fwiw, #2 is almost certainly what we'll do with bionic too.) > > But if > > it's possible to do correct rounding in a way that's all-wins > > (performance, size, quality of results) or nearly all wins (maybe > > slightly larger?), at least for select functions, that seems very > > interesting. > > If you look at Table II from https://hal.inria.fr/hal-03721525, you see > that > for *single* precision functions (binary32), indeed that's all-wins. > > Best regards, > Paul > > --000000000000f78fc205e80ab969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 5, 2022 at 2:09 AM Paul Z= immermann <Paul.Zimmermann@i= nria.fr> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Dear Rich,

> Could you summaraize briefly what you have in mind, and what tradeoffs=
> might be? Are these intended to be drop-in replacements for the
> existing standard functions, or implementations for the "cr"= versions
> thereof? I have not followed closely the "mandatory requirement o= f
> correct rounding for mathematical functions in the next revision of > the IEEE-754 standard" topic and how it relates to the future of = C,
> but my vague recollection was that the direction folks were leaning > was towards a separate set of cr*() functions or something.

the current situation is:

- IEEE 754 does not require correct rounding for mathematical functions

- indeed, the C2X standard will reserve cr_xxx names for correctly rounded<= br> =C2=A0 functions

- thus mathematical libraries will have essentially 3 choices:

0) either provide incorrectly rounded functions as (say) exp.
=C2=A0 =C2=A0This is the current situation.

1) provide incorrectly rounded functions as exp, and correctly rounded
=C2=A0 =C2=A0functions as cr_exp.

2) or provide only exp, with correct rounding (then cr_exp could be an alia= s
=C2=A0 =C2=A0for exp)

It seems that LLVM-libc will go for 2), I have no news from other libraries= .

(fwiw, #2 is almost certainly what we= 'll do with bionic too.)
=C2=A0
> But if
> it's possible to do correct rounding in a way that's all-wins<= br> > (performance, size, quality of results) or nearly all wins (maybe
> slightly larger?), at least for select functions, that seems very
> interesting.

If you look at Table II from https://hal.inria.fr/hal-03721525,= you see that
for *single* precision functions (binary32), indeed that's all-wins.
Best regards,
Paul

--000000000000f78fc205e80ab969--