From owner-freebsd-standards@FreeBSD.ORG Thu May 30 16:56:14 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BF9A8E8; Thu, 30 May 2013 16:56:14 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (50-196-151-174-static.hfc.comcastbusiness.net [50.196.151.174]) by mx1.freebsd.org (Postfix) with ESMTP id 614A1690; Thu, 30 May 2013 16:56:13 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.7/8.14.2) with ESMTP id r4UGuBTH093763; Thu, 30 May 2013 09:56:11 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.7/8.14.2/Submit) id r4UGuARj093762; Thu, 30 May 2013 09:56:10 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 30 May 2013 09:56:10 -0700 From: David Schultz To: Warner Losh Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Message-ID: <20130530165610.GA93684@zim.MIT.EDU> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <20130530064635.GA91597@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Stephen Montgomery-Smith , pfg@freebsd.org, freebsd-standards@freebsd.org, freebsd-numerics@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:56:14 -0000 On Thu, May 30, 2013, Warner Losh wrote: > > On May 30, 2013, at 12:46 AM, David Schultz wrote: > > On Fri, Feb 22, 2013, David Chisnall wrote: > > I was wondering if you could explain a bit about what your goal is > > here, though. Is there some kind of certification you are trying > > to achieve? Why can't you just comment out the few missing > > functions? You've been adamant about this issue ever since > > joining the Project, even suggesting that we commit bogus > > implementations just for the sake of having the symbols. I > > completely agree with you that the lack of progress is > > unacceptable, and I'm sorry I haven't had more time to work on > > this stuff myself, but I also don't understand the source of your > > urgency. > > More and more projects are refusing to work around our > gridlock. We have to report R each new release because they have > taken out the checks for the missing symbols. It is really an > embarrassment to the project. We've let the perfect be the enemy > of the good. There are R scripts that run elsewhere and not on > FreeBSD. R is the one I know most about since I've been using R > a lot to crunch numbers for work, but there are others. > > The urgency is we'd like to have this stuff done for 10, if at > all possible. And if not done, then a lot closer to done than > where we are today. It looks like the R in ports just wants logl(), which isn't surprising, and there's already code for that. So getting that in for 10 is achievable. > > The reason I'm asking is that I'm pushing to get a lot of stuff > > into the tree quickly, but realistically, in the short term we're > > only going to get 95% of the way there. I doubt good > > implementations of complicated functions that nobody uses, such as > > erfcl() and tgammal(), are going to appear overnight. Thus, I > > would like to know whether the last 5% is needed quickly, and if > > so, why. > > I'm all for getting everything we can into the tree that > produces an answer that's not perfect, but close. What's the > error that would be generated with the naive implementation of > > long double tgammal(long double f) { return tgamma(f); } > > But assuming that, for some reason, produces errors larger than > difference in precision between double and long double due to > extreme non-linearity of these functions, having only a couple > of stragglers is a far better position to be in than we are > today. Whether this is acceptable depends a lot on who needs it in the first place, which is part of why I was asking. For many years, the only software that cared was libstdc++, and libstdc++ only wanted to wrap it. Here are some of my notes on the status of things: long double log2l(long double); -- bde long double logl(long double); -- bde long double log1pl(long double); -- bde Bruce has these written. We can commit them with a little cleanup. long double acoshl(long double); -- sgk long double asinhl(long double); -- sgk long double atanhl(long double); -- sgk long double log10l(long double); -- bde These are trivial given the first three. I believe Bruce and Steve have the code for them already. long double expl(long double); -- sgk long double expm1l(long double); -- sgk Steve has perfectly committable patches that I've already approved (and furthermore, he doesn't need my approval anymore!) long double coshl(long double); long double sinhl(long double); long double tanhl(long double); long double erfcl(long double); long double erfl(long double); These are easy given expl() and expm1l(). long double powl(long double, long double); This is not so easy, but important, so we can make it a priority. long double lgammal(long double); long double tgammal(long double); These are neither easy nor important; this gets back to my question. float complex clogf(float complex); -- bde double complex clog(double complex); -- bde Bruce has code for these, which should be straightforward to turn into something committable. float complex cpowf(float complex, float complex); double complex cpow(double complex, double complex); This one is tough to do well and even tougher to test -- lots of nasty corner cases. long double complex cexpl(long double complex); long double complex ccosl(long double complex); long double complex ccoshl(long double complex); long double complex csinl(long double complex); long double complex csinhl(long double complex); long double complex ctanl(long double complex); long double complex ctanhl(long double complex); long double complex cacosl(long double complex); long double complex cacoshl(long double complex); long double complex casinl(long double complex); long double complex casinhl(long double complex); long double complex catanl(long double complex); long double complex catanhl(long double complex); long double complex clogl(long double complex); long double complex cpowl(long double complex, long double complex); The long double versions of the complex math functions are trivial once the long double versions of the corresponding real functions are written.