[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 05 Sep 2022 11:09:04 +0200
From: Paul Zimmermann <Paul.Zimmermann@...ia.fr>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: integration of CORE-MATH routines into Musl?
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.
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
