Re: Use of C99 extra long double math functions after r236148

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 <sgk_at_troutmask.apl.washington.edu> 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