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

On 05/28/2012 05:17 PM, Steve Kargl wrote:
> On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:
>> On 05/28/2012 03:31 PM, Steve Kargl wrote:
>>> On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
>>>> One thing that could be done is to have a "math/cephes" port that adds
>>>> the extra C99 math functions.  This is already done in the math/sage
>>>> port, using a rather clever patch due to Peter Jeremy, that applies to
>>>> the cephes code.
>>>>
>>>> What it would do is to create a /usr/local/lib/libm.so that would
>>>> provide the extra functions not currently included in /lib/libm.so, and
>>>> then link in /lib/libm.so as well.  It would also create its own
>>>> /usr/local/include/math.h and /usr/local/include/complex.h as well.
>>>>
>>>> What do you guys think?  Do you want someone to start experimenting with
>>>> this idea?  I could do it, but probably not for a little while.
>>>>
>>>
>>> This is a horrible, horrible, horrible idea.  Have you
>>> looked at the cephes code, particularly the complex.h
>>> functions?
>>
>> I have only taken a very cursory look.  What should I specifically look
>> for in seeing that the code is bad?
>
> Well, to start with, the extra C99 math functions that
> are missing in libm include a few for the long double type
> and many (if not most) of the complex functions for any
> type.  Cephes at best will give you float, double, and ld80, but
> not ld128 versions of the functions.  Then, there is fun little fact
> that neither (base) gcc nor clang nor gcc less than 4.6 does
> complex arithematic correctly; so, one needs to jump through
> hoops to get the correct answer (See Annex G in n1256.pdf).
> One item of particular importance in Annex G is the behavior
> of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
> NaN.
>

IMHO these problems are definitely not bad enough to avoid making a 
math/cephes port.  I for one would definitely like to have some kind of 
implementation of ccosh, even if it gets a few things wrong when it is 
fed Nan or I*Inf or such like as its input.  I mean, if clang or gcc46 
doesn't even get this right, how can we expect better from libm?

Also, a really nice thing about Jeremy's patch is that it automatically 
detects which functions are already included in the base libm, and only 
adds functions not already in libm.

And ld80 is better than nothing if ld128 isn't available.

I would avoid cephes only if it got some of the answers horribly wrong 
(as in erf(100) being something like -14232 as the openoffice 
implementation of the erf function used to report).

I say, lets go ahead and add a math/cephes port.

By the way, do you have an opinion on the complex functions used in 
Linux?  (I tried reading the glibc code, but I could only find chains of 
macros and functions calling each other, and I could never find where 
the actual work was performed.)