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

On 09.07.2012 01:36 (UTC+2), Steve Kargl wrote:
> 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.

Do you think your version from 
http://www.freebsd.org/cgi/query-pr.cgi?pr=152415 for expl() ld80 
version could be the one getting into head? Would you be willing to 
commit it?

As far as I understand from discussions on R mailing list 
(r-devel_at_r-project.org), they plan to reduce the emulation and/or 
workaround of long and complex math functions for FreeBSD and other 
systems with their next releases of R devel. So we could really need 
some progress with our C99 conform math functions ;-)

>>> 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.
>
>