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

From: David Schultz <das_at_FreeBSD.ORG>
Date: Sun, 8 Jul 2012 08:40:47 -0400
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.

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.
Received on Sun Jul 08 2012 - 11:10:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC