From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 17:52:00 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 CC1471065672 for ; Sun, 8 Jul 2012 17:52:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 905E08FC15 for ; Sun, 8 Jul 2012 17:52:00 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19177103pbb.13 for ; Sun, 08 Jul 2012 10:52:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=eTj7yQhuvGXLfSUV5eJBHuMjRAIikBt+v8WH9O/TEQs=; b=Z6FeKjS+bUD858DAZx3/0tasdUUGxxZ4IB9PGEb5GYQmJmcZ8Hp+sEEZq7ZOEIGgNR IZA4abcXV4+j7ymbhd93YTFGxZFoPB3L4MObn9diFqqZniw3SDrcBfVtcf8ARl9jkVUK wSzRoyy7YSAbshA9YI1/isUNMHzfi55XM6hp/67F+p2aDcqnk8srgDcXMhBh+a0itj/Z cFQBtnHYByqcbJaQftYfTXd/UoVljHr2PHP7+0AzPAP5MZ9m70Ee4YqFjAbJ0iH7Ge/S lEhI7C3u0oq3IK43afOIM5hsswmh83o1Vqd4uqHv8Kwjb+RGr50Uj9waVdTG4Jrby4PY Dvpw== Received: by 10.66.82.228 with SMTP id l4mr23423418pay.41.1341769920319; Sun, 08 Jul 2012 10:52:00 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id hf5sm26053369pbc.4.2012.07.08.10.51.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 10:51:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120708124047.GA44061@zim.MIT.EDU> Date: Sun, 8 Jul 2012 11:51:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> References: <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> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkLSKV5epsw0iV9Ky+rDzr0ppD8zgZWC+nYKE5/RXsw88wmkBREIWFvm9wyK91p0t3jFPvv Cc: freebsd-current@FreeBSD.ORG, Peter Jeremy , Steve Kargl 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: Sun, 08 Jul 2012 17:52:00 -0000 On Jul 8, 2012, at 6:40 AM, David Schultz wrote: > On Tue, May 29, 2012, Peter Jeremy wrote: >> 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. >>=20 >> Well, most of cephes was written before C99. The C99 parts of >> cephes were written to turn it into a complete C99 implementation. >=20 > I'm a bit late to the party, but I thought I'd chime in with some > context. We did consider using Cephes years ago, and even got > permission from the author to release it under an acceptable license. > We later decided not to use it for technical reasons. >=20 > By the way, virtually none of the people who have complained about the > missing functions actually need them. Mostly they just want to > compile some software that was written by a naive programmer who > thought it would be cool to use the most precise type available. The > complex functions are even less commonly needed, and the truth is that > they have no business being part of the C standard anyway. >=20 > The question remains of what to do about the missing functions. Bruce > and Steve have been working on expl and logl for years. If those ever > get in the tree, the remaining long double functions are easy. Those > functions are basically done, modulo a bunch of cleanup and testing, > and I encourage any mathematically inclined folks who are interested > in pushing things along to get in touch with them. I'm not going to > have any time myself for a few months at least. Where can I find these? > Lastly, there's the question of mediocre alternatives, such as > solutions that get the boundary cases wrong or don't handle 128-bit > floating point. For the exponential and logarithmic functions, Bruce > and Steve have already written good implementations, so there's no > reason to settle for less. As for the other long double functions, > bringing in some Cephes code in a separate directory as a temporary > fix might be the way to go. I don't like that solution, and Steve > raises some good technical points about why it isn't ideal; however, a > better solution is more than a decade overdue, and people are > justified in finding that unacceptable. Don't let the perfect be the enemy of the good. It is better to have OK = implementations of these functions than none at all. We originally had = so-so double support, but bruce spent many years optimizing them to make = them very good. If we were just starting out, and hadn't let 10 years = get behind us, I'd give the substandard argument some weight. But now = that we're 13 years down the line from c99's publication I think we need = to relax our standards a bit. I'd even argue that these functions being = a little bad could easily spur people to make them better. Their = absence makes people just #define llexp(x) lexp(x), etc. :( Warner Warner=