Date: Mon, 23 Jan 2012 12:07:15 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: libm On Mon, Jan 23, 2012 at 05:41:52PM +0100, Szabolcs Nagy wrote: > i've looked into libm implementations > to figure out what's best for musl Thanks!! > * reproducible semantics: Unless others are deeply committed to having results match other platforms/libcs bit-for-bit, this is not a major concern for me. I'm happy with bit-exact just for non-transcendental (i.e. sqrt) and 1ulp (or even several ulp) max error for transcendental functions. > * 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. > * 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. > 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 complex functions are simple once elementary > functions are there (bsd libcs has bsd licensed > implementations of these) Well they don't have any more difficult numeric analysis issues, but there are quite a few corner cases with complex functions which many platforms have gotten wrong (issues with branch cuts and signed zeros, etc.). > conclusion: > > the simplest approach for musl at this point is to > reuse the already available math functions > (+run the available tests on them) I generally agree, provided no major bugs are found - and even if they are, they should be fixable. > this can be done by diffing the various bsd and glibc > functions and choosing the best one (usually they are > the same except code organization and bit manipulation > details) That was my impression too. > code and ideas from crlibm might be possible to use > but that would take much more effort and knowledge > (assuming we want small code size) Yes, crlibm looks very interesting but also very large... > designing new algorithms for elementary functions seems > to require a huge effort and the best tradoffs are not > even clear Agreed. I think it's roughly as big a task as the rest of musl combined, so it's best not to go there. Rich
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.