Date: Mon, 28 May 2012 18:03:37 -0500 From: Stephen Montgomery-Smith <stephen@missouri.edu> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 Message-ID: <4FC40449.3040602@missouri.edu> In-Reply-To: <20120528221731.GA76723@troutmask.apl.washington.edu> References: <4FC30090.4070003@gwdg.de> <4D8CF7D2-CBEE-438E-A9E7-9C47A8892622@FreeBSD.org> <4FC36FE1.9080908@gwdg.de> <DFE44442-A1B1-40B3-9A79-874BD2BE45E7@FreeBSD.org> <4FC38B81.6000302@gwdg.de> <4FC3A154.8030702@missouri.edu> <20120528203159.GA76340@troutmask.apl.washington.edu> <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/28/2012 05:17 PM, Steve Kargl wrote: > On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote: >> On 05/28/2012 03:31 PM, Steve Kargl wrote: >>> On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote: >>>> One thing that could be done is to have a "math/cephes" port that adds >>>> the extra C99 math functions. This is already done in the math/sage >>>> port, using a rather clever patch due to Peter Jeremy, that applies to >>>> the cephes code. >>>> >>>> What it would do is to create a /usr/local/lib/libm.so that would >>>> provide the extra functions not currently included in /lib/libm.so, and >>>> then link in /lib/libm.so as well. It would also create its own >>>> /usr/local/include/math.h and /usr/local/include/complex.h as well. >>>> >>>> What do you guys think? Do you want someone to start experimenting with >>>> this idea? I could do it, but probably not for a little while. >>>> >>> >>> This is a horrible, horrible, horrible idea. Have you >>> looked at the cephes code, particularly the complex.h >>> functions? >> >> I have only taken a very cursory look. What should I specifically look >> for in seeing that the code is bad? > > Well, to start with, the extra C99 math functions that > are missing in libm include a few for the long double type > and many (if not most) of the complex functions for any > type. Cephes at best will give you float, double, and ld80, but > not ld128 versions of the functions. Then, there is fun little fact > that neither (base) gcc nor clang nor gcc less than 4.6 does > complex arithematic correctly; so, one needs to jump through > hoops to get the correct answer (See Annex G in n1256.pdf). > One item of particular importance in Annex G is the behavior > of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and > NaN. > IMHO these problems are definitely not bad enough to avoid making a math/cephes port. I for one would definitely like to have some kind of implementation of ccosh, even if it gets a few things wrong when it is fed Nan or I*Inf or such like as its input. I mean, if clang or gcc46 doesn't even get this right, how can we expect better from libm? Also, a really nice thing about Jeremy's patch is that it automatically detects which functions are already included in the base libm, and only adds functions not already in libm. And ld80 is better than nothing if ld128 isn't available. I would avoid cephes only if it got some of the answers horribly wrong (as in erf(100) being something like -14232 as the openoffice implementation of the erf function used to report). I say, lets go ahead and add a math/cephes port. By the way, do you have an opinion on the complex functions used in Linux? (I tried reading the glibc code, but I could only find chains of macros and functions calling each other, and I could never find where the actual work was performed.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC40449.3040602>