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

On 05/31/12 10:45, John Baldwin wrote:
> On Monday, May 28, 2012 7:02:18 pm Steve Kargl wrote:
>> On Tue, May 29, 2012 at 07:05:07AM +1000, Peter Jeremy wrote:
>>> On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith
> <stephen_at_missouri.edu>  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.
>>>
>>> Basically, as long as the compiler searches /usr/local/{include,lib}
>>> before the base include/lib then<math.h>,<complex.h>  and -lm give
>>> the application a complete C99 math implementation by using base
>>> functions where they exist and cephes functions where they don't.
>>>
>>> The patch I wrote for sage can be found at
>>> http://trac.sagemath.org/sage_trac/ticket/9543
>>> If there's any interest, I could produce a port for this.
>>>
>>> Another option would be to import cephes into base and use it to
>>> provide the missing C99 functions.  Cephes includes copyright notices
>>> but the closest I can find to a license is:
>>> "   Some software in this archive may be from the book _Methods and
>>>   Programs for Mathematical Functions_ (Prentice-Hall or Simon&  Schuster
>>>   International, 1989) or from the Cephes Mathematical Library, a
>>>   commercial product. In either event, it is copyrighted by the author.
>>>   What you see here may be used freely but it comes with no support or
>>>   guarantee."
>>
>> Please talk to das_at_ (although I believe he's finishing up his
>> dissertation).  I recall that he's stated that he looked into
>> using cephes, and concluded that it is not suitable for libm.
>>
>> Note there is also
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599
>>
>> which I've also objected to importing into libm.
>
> I do think we should provide something in ports as an interim solution.
> There are other 3rd party applications looking to drop FreeBSD support
> because we are missing APIs that almost all other OS's have.  I'm fine
> if the interim lives in ports and that we don't import substandard
> routines into the base.  I would even be fine with calling it
> /usr/local/lib/libm_inaccurate.so.  However, I do think we need an option.
>

I think it should be called libm.so.  Otherwise we have to do a serious 
editing job on the Makefiles/configure scripts.

sed -E 's/[[:<:]]-lm[[:>:]]/-lm_inaccuarate/'

might have some false positives and false negatives.  (Did I even get 
the sed syntax correct?)



By the way, I was looking through:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599

They say they compute cosh(2y) - cos(2x) using Taylor's series.  I would 
agree with Steve that this is seriously low quality.  Floating point 
errors are likely to be truly horrible.  This will fail even for 
non-edge cases.  (This was the same error that openoffice used to have 
for computing erf(x), that gave things like erf(100) = -4353243242.)