Date: Thu, 30 May 2013 09:56:10 -0700 From: David Schultz <das@FreeBSD.ORG> To: Warner Losh <imp@bsdimp.com> Cc: Stephen Montgomery-Smith <stephen@missouri.edu>, pfg@freebsd.org, freebsd-standards@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: standards/175811: libstdc++ needs complex support in order use C99 Message-ID: <20130530165610.GA93684@zim.MIT.EDU> In-Reply-To: <A3633CF7-B0D3-4E09-88FC-1D40197C652C@bsdimp.com> References: <201302040328.r143SUd3039504@freefall.freebsd.org> <510F306A.6090009@missouri.edu> <C5BD0238-121D-4D8B-924A-230C07222666@FreeBSD.org> <20130530064635.GA91597@zim.MIT.EDU> <A3633CF7-B0D3-4E09-88FC-1D40197C652C@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130530165610.GA93684>