From owner-freebsd-current@FreeBSD.ORG Tue May 29 04:56:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E4F1106564A for ; Tue, 29 May 2012 04:56:22 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id EF0F48FC22 for ; Tue, 29 May 2012 04:56:21 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q4T4uKFP049482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 14:56:20 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q4T4uDO8045674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 14:56:13 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q4T4uDd8045672; Tue, 29 May 2012 14:56:13 +1000 (EST) (envelope-from peter) Date: Tue, 29 May 2012 14:56:13 +1000 From: Peter Jeremy To: Steve Kargl Message-ID: <20120529045612.GB4445@server.rulingia.com> References: <4FC38B81.6000302@gwdg.de> <4FC3A154.8030702@missouri.edu> <20120528203159.GA76340@troutmask.apl.washington.edu> <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline In-Reply-To: <4FC43C8F.5090509@missouri.edu> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 04:56:22 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-May-28 15:54:06 -0700, Steve Kargl wrote: >Given that cephes was written years before C99 was even >conceived, I suspect all functions are sub-standard. Well, most of cephes was written before C99. The C99 parts of cephes were written to turn it into a complete C99 implementation. > For >example, AFAIK, none of the long double functions are >appropriate for any platform that has an 128-bit long double; >as cephes was written for an Intel 80-bit format. FreeBSD currently supports: 64-bit long doubles on ARM, MIPS and PowerPC; 80-bit long doubles on amd64, i386 and iA64; 128-bit long doubles on SPARC. The lack of LD128 in cephes therefore only affects one (not widely used) platform. The lack of even de facto standards for long double mean that any applications wanting to use them already need to cope with at least a 2:1 precision range. >If portmgr or a port maintainer wants to use a library with >untested implementations of missing libm functions, please do >not put it into /usr/local/lib and call it libm. There some test code in cephes. Can you point me to a suitable test suite for LD80 and LD128? The reason for calling it libm is to avoid having to hack every consumer to add an additional library. On 2012-May-28 16:30:35 -0700, Steve Kargl wrote: >Who's writing the code to test the implementations? That is >better much the problem. Without testing, one might get an >implementation that appears to work until it doesn't! That is equally true of the rest of FreeBSD. The list of open PRs suggests that FreeBSD still has a fair way to go before reaching perfection. And, most of this thread has been about using this code in ports - where the bar is much lower. Who is writing the code to test all the other ports? What is so special about this particular proposed port that it needs to come with solid-gold credentials? > It took >me 3+ years to get sqrtl() into libm, but bde and das (and >myself) wanted to make sure the code worked. Last time I checked (a couple of years ago), FreeBSD was missing 65 C99 libm functions. At 3 years per function, we should have C99 support available early in the 23rd century - which may be a bit late. On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smith wrote: >1. By being so picky about being so precise, FreeBSD is behind the time= =20 >line in rolling out a usable set of C99 functions. And at the current rate, we'll all be long dead before they are available. Whilst I'd far prefer to have a properly verifed library function, I think we are better off with an implementation that has some caveats regarding edge-case behaviour than having nothing. >In the end, I do think it is good to ultimately settle on good C99=20 >compliant code. But having something intermediate that mostly works is=20 >better than nothing. Especially if it exists only in the ports, and not= =20 >in the base code. I agree with this sentiment. What do people do on other free OSs? Does a tested open source C99 libm exist anywhere? glibc implements cpow(x,y) as cexp(y*clog(x)) and cephes does better than that. Is FreeBSD wasting its time writing "correct" C99 code because all the libm consumers expect no better than what glibc offers? I agree that writing correct libm functions is hard. I think a lot of the problem is that it's a mix of lots of boilerplate code testing for special conditions and edge cases that is boring to write and fiddly to get right, together with a kernel that is a pile of polynomial evaluations full of magic numbers that needs specialist skills to write. If we could get someone with the relevant skills to formally list all the special conditions & edge cases for each function, it should be possible to generate both the library C code and test cases =66rom that - which would remove a lot of the tedium. --=20 Peter Jeremy --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/EVuwACgkQ/opHv/APuIfVqACgqMUFgkAeTH02YyrPChR27JTO 17sAoICBiq7poaxgUde3aBLX/kr8U1mu =p+zi -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5--