From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/550 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: libm Date: Mon, 23 Jan 2012 20:12:15 +0100 Message-ID: <20120123191215.GA31975@port70.net> References: <20120123164152.GZ31975@port70.net> <20120123170715.GA197@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1327345955 8341 80.91.229.12 (23 Jan 2012 19:12:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2012 19:12:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-551-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 23 20:12:31 2012 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1RpPJc-0000Je-JL for gllmg-musl@lo.gmane.org; Mon, 23 Jan 2012 20:12:28 +0100 Original-Received: (qmail 31878 invoked by uid 550); 23 Jan 2012 19:12:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 31870 invoked from network); 23 Jan 2012 19:12:28 -0000 Content-Disposition: inline In-Reply-To: <20120123170715.GA197@brightrain.aerifal.cx> User-Agent: Mutt/1.5.20 (2009-06-14) Xref: news.gmane.org gmane.linux.lib.musl.general:550 Archived-At: * Rich Felker [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)