From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 23:42:44 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2777A1065673; Sun, 8 Jul 2012 23:42:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4FC8FC18; Sun, 8 Jul 2012 23:42:43 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q68NaPBE053527; Sun, 8 Jul 2012 16:36:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q68NaO5K053526; Sun, 8 Jul 2012 16:36:24 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2012 16:36:24 -0700 From: Steve Kargl To: Warner Losh Message-ID: <20120708233624.GA53462@troutmask.apl.washington.edu> References: <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> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: David Schultz , freebsd-current@FreeBSD.ORG, Peter Jeremy 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 23:42:44 -0000 On Sun, Jul 08, 2012 at 11:51:56AM -0600, Warner Losh wrote: > > 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. > >> > >> Well, most of cephes was written before C99. The C99 parts of > >> cephes were written to turn it into a complete C99 implementation. > > > > 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. > > > > 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. > > > > 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? I've posted expl() a few times for the ld80 version. I don't have an ld128 version, which is why I have yet to submit a formal patch for expl(). I also have an ld80 expm1l(). I have a copy of bde's ld80 logl(). IIRC, bde wrote an ld128, but I don't have nor do I know if it has been tested. > > 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. You'll need to define OK, because some of the implementations I've read are poor. I also hope that before anything is committed to libm that the person doing the committing does some rather thorough testing of the code. > 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. :( Of course, the converse argument is that people have had 10 years to learn enough about floating point to actually write and submit code. I knew very little about FP before I wrote sqrtl(). I had a need for sqrtl() and so I went looking for a solution. PS: I also wrote sincos[fl](), which is very handy for the complex trig functions. -- Steve