Re: correctly rounded mathematical functions

[Joel Sherrill <joel@rtems.org>]

On Mon, Jan 3, 2022 at 6:58 AM Paul Zimmermann <Paul.Zimmermann@inria.fr> wrote:
>
>       Dear Newlib developers,
>
> the current C working draft [1, p392] has reserved names for correctly
> rounded functions (cr_exp, cr_log, cr_sin, ...).
>
> We propose to provide such correctly rounded implementations
> for the three IEEE formats (binary32, binary64, binary128) and the
> "extended double" format (long double on x86_64).
>
> These implementations will be correctly rounded for all rounding modes,
> for example one could do the following to emulate interval arithmetic:
>
>    fesetround (FE_DOWNWARD);
>    y_lo = cr_exp (x_lo);
>    fesetround (FE_UPWARD);
>    y_hi = cr_exp (x_hi);
>
> Users who want a fast implementation will call the exp/log/sin/... functions,
> users who want a correctly rounded function and thus reproducible results
> (whatever the hardware, compiler or operating system) will use the
> cr_exp/cr_log/cr_sin/... functions. Our goal is nevertheless to get the
> best performance possible.
>
> Our objective is to provide open-source implementations that can be integrated
> in the major mathematical libraries (GNU libc, Intel Math Library, AMD Libm,
> Redhat Newlib, OpenLibm, Musl, llvm-libc, CUDA, ROCm).
>
> Are developers of Newlib interested by such functions?
> If so, we could discuss what would be the requirements for integration in
> Newlib in terms of license, table size, allowed operations.

Speaking from the RTEMS perspective, we are very interested
in the addition of more POSIX and C Standard Library methods.
We have been having GSoC students add them where possible
for a few years.

The license has to be permissive and should have no advertising
although based on COPYING.NEWLIB, some must have a BSD
advertising clause still. Possibly those need review.

https://sourceware.org/git/?p=newlib-cygwin.git;a=blob_plain;f=COPYING.NEWLIB;hb=HEAD

As long as the method's footprint only impacts applications that use
it, there shouldn't be a huge concern on size but the target domain is
mostly smaller single process, no-MMU embedded systems. That is
ignoring Cygwin which has fewer constraints.  If you end up adding
megabytes, that's going to be bad in general.



> We have started to work on two functions (cbrt and acos), for which we
> provide presumably correctly rounded implementations (up to the knowledge
> of hard-to-round cases) [2].

Great! What's the size profile on those?

What's the minimum compiler or C language version to build these?

--joel

>
> Christoph Lauter
> Jean-Michel Muller
> Alexei Sibidanov
> Paul Zimmermann
>
> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
> [2] https://homepages.loria.fr/PZimmermann/CORE-MATH/