Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120123191215.GA31975@port70.net>
Date: Mon, 23 Jan 2012 20:12:15 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: libm

* Rich Felker <dalias@...ifal.cx> [2012-01-23 12:07:15 -0500]:
> On Mon, Jan 23, 2012 at 05:41:52PM +0100, Szabolcs Nagy wrote:
> > * tradeoffs:
> > 
> > modern libms (libmcr, libultim, crlibm) try to guarantee
> > correctness but arg reduction and faithful (or even
> > correct) rounding is hard to do and hard to verify
> 
> Correct arg reduction is important to me. Incorrect arg reduction is
> equivalent to billions of billions of ulp error in the final results.
> 

yes, but trigonometric arg reduction is a real pain
and ppl shouldn't use large arguments there anyway..

so there are arguments both ways
but this is already reasonably
solved in fdlibm

> > * libms in practice:
> > 
> > many functions are the same in glibc and the various
> > bsd libcs (they are mostly based on fdlibm, but glibc
> > 64bit double precision functions are from the gpl
> > licensed libultim)
> 
> You really mean double, not extended? That's odd since fdlibm covers
> double.. I wonder when/why they switched.
> 

i forgot to mention that both the bsds and glibc have most of the
functions implemented in i387 asm (using the builtin instructions),
i'm not sure how far musl wants to take that

the generic 64bit double c code of glibc is from fdlibm and libultim
but libultim provides the important elementary functions (exp, log, pow,
sin, atan,..) while fdlibm the more obscure or simple ones (floor, rint,
fabs, cosh, tanh, j0, erf,..)

$ grep '* IBM' glibc/sysdeps/ieee754/dbl-64/*.c |wc -l
25
$ grep 'Copyright .* Sun' glibc/sysdeps/ieee754/dbl-64/*.c |wc -l
33

the libultim functions provide correct rounding but can be slow
(they use multiprecision arithmetic for various things and
eg for arg reduction they increase the precision until it's enough)

> > the extended precision algorithms are reused across
> > different libcs as well, but there are 80bit vs 128bit
> > differences. the correctness of extended precision
> > algorithms are much less studied (eg there are no
> > correctly rounded versions or worstcases for 2pi arg
> > reductions)
> 
> Any ideas how the different ones evolved (separately written or common
> ancestor code, etc.) and where we should look to pull code from?
> 

most of the available *l (and *f) code is based on fdlibm
but ported by someone to long double (or float)

openbsd and freebsd mostly use the same code by the same contributors
as far as i can see, but they have separate 80bit and 128bit variants
for important elementary functions

glibc is sometimes the same as the bsds but often not (eg expl and
sinl are clearly different)

i don't think there are other available widely used implementations
so we have openbsd, freebsd and glibc
(mathcw has long double functions but i don't see source code and
it does not seem to be active)

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.