mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Paul Zimmermann <Paul.Zimmermann@inria.fr>
Cc: musl@lists.openwall.com, sibid@uvic.ca,
	christoph.lauter@christoph-lauter.org,
	Jean-Michel.Muller@ENS-LYON.FR
Subject: Re: [musl] correctly rounded mathematical functions
Date: Mon, 3 Jan 2022 21:29:05 -0500	[thread overview]
Message-ID: <20220104022905.GB7074@brightrain.aerifal.cx> (raw)
In-Reply-To: <mw7dbhotlc.fsf@tomate.loria.fr>

On Mon, Jan 03, 2022 at 02:07:59PM +0100, Paul Zimmermann wrote:
>       Dear Musl 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 Musl interested by such functions?
> If so, we could discuss what would be the requirements for integration in
> Musl in terms of license, table size, allowed operations.

License: should be licensed under something permissive and
MIT-compatible, preferably explicitly MIT if you'll be
dual-/multi-licensing anyway.

Table size: main consideration is that tables need to be pure
shareable rodata, so no runtime generation of contents or pointers in
contents. Failure to follow this would produce significant cost in
*all processes* even ones that don't use the cr_* functions. I would
hope they'd also fit in a few tens of kB of rodata, but I don't know
how realistic that is.

Allowed operations: I'm not sure what the scope of this question is.
Are you asking if things like changing rounding mode would be okay? Or
something else. musl implements C11 and hopefully future versions of
the language library, but is implemented in C99 (+ very minimal set of
common/"GNU C" extensions), so code to be included in musl shouldn't
depend on new language features or compiler extensions not already
used (at least without checking on them first). We also have
softfloat-only targets and targets with excess precision, so code
should be compatible with those (which means not depending on changing
fenv; see commit 4f3d346bffdf9ed2b1803653643dc31242490944 for an
example of where this came up).

> 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].
> 
> 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/

Is there a standalone version of the code where it can be read in full
not as a patch to glibc? Is the code being developed in such a way
that it's not potentially a derivative work of the glibc versions?

Rich

  parent reply	other threads:[~2022-01-04  2:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-03 13:07 Paul Zimmermann
2022-01-04  0:04 ` Damian McGuckin
2022-01-04  2:29 ` Rich Felker [this message]
2022-01-04 14:19   ` Paul Zimmermann
2022-01-04 21:12     ` Szabolcs Nagy
2022-01-06  8:55       ` Paul Zimmermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220104022905.GB7074@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=Jean-Michel.Muller@ENS-LYON.FR \
    --cc=Paul.Zimmermann@inria.fr \
    --cc=christoph.lauter@christoph-lauter.org \
    --cc=musl@lists.openwall.com \
    --cc=sibid@uvic.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).