[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 04 Jan 2022 15:19:48 +0100
From: Paul Zimmermann <Paul.Zimmermann@...ia.fr>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, sibid@...c.ca,
christoph.lauter@...istoph-lauter.org,
Jean-Michel.Muller@...-LYON.FR
Subject: Re: correctly rounded mathematical functions
Hi Rich,
> License: should be licensed under something permissive and
> MIT-compatible, preferably explicitly MIT if you'll be
> dual-/multi-licensing anyway.
ok, we'll consider multi-licensing with MIT.
> 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.
tables so far are "static const"
> 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 avoid playing with fesetround/fegetround since in general this makes
the code slower
> > 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?
yes there are several standalone versions of the code (entries marked "full"
on https://homepages.loria.fr/PZimmermann/CORE-MATH/).
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.
