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

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.

>  For
>example, AFAIK, none of the long double functions are
>appropriate for any platform that has an 128-bit long double;
>as cephes was written for an Intel 80-bit format.

FreeBSD currently supports:
64-bit long doubles on ARM, MIPS and PowerPC;
80-bit long doubles on amd64, i386 and iA64;
128-bit long doubles on SPARC.

The lack of LD128 in cephes therefore only affects one (not widely
used) platform.  The lack of even de facto standards for long
double mean that any applications wanting to use them already need
to cope with at least a 2:1 precision range.

>If portmgr or a port maintainer wants to use a library with
>untested implementations of missing libm functions, please do
>not put it into /usr/local/lib and call it libm.

There some test code in cephes.  Can you point me to a suitable test
suite for LD80 and LD128?  The reason for calling it libm is to avoid
having to hack every consumer to add an additional library.

On 2012-May-28 16:30:35 -0700, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:
>Who's writing the code to test the implementations?  That is
>better much the problem.  Without testing, one might get an
>implementation that appears to work until it doesn't!

That is equally true of the rest of FreeBSD.  The list of open PRs
suggests that FreeBSD still has a fair way to go before reaching
perfection.  And, most of this thread has been about using this code
in ports - where the bar is much lower.  Who is writing the code to
test all the other ports?  What is so special about this particular
proposed port that it needs to come with solid-gold credentials?

>  It took
>me 3+ years to get sqrtl() into libm, but bde and das (and
>myself) wanted to make sure the code worked.

Last time I checked (a couple of years ago), FreeBSD was missing 65
C99 libm functions.  At 3 years per function, we should have C99
support available early in the 23rd century - which may be a bit late.

On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smith <stephen_at_missouri.edu> wrote:
>1.  By being so picky about being so precise, FreeBSD is behind the time 
>line in rolling out a usable set of C99 functions.

And at the current rate, we'll all be long dead before they are
available.  Whilst I'd far prefer to have a properly verifed library
function, I think we are better off with an implementation that has
some caveats regarding edge-case behaviour than having nothing.

>In the end, I do think it is good to ultimately settle on good C99 
>compliant code.  But having something intermediate that mostly works is 
>better than nothing.  Especially if it exists only in the ports, and not 
>in the base code.

I agree with this sentiment.

What do people do on other free OSs?  Does a tested open source C99
libm exist anywhere?  glibc implements cpow(x,y) as cexp(y*clog(x))
and cephes does better than that.  Is FreeBSD wasting its time writing
"correct" C99 code because all the libm consumers expect no better
than what glibc offers?

I agree that writing correct libm functions is hard.  I think a lot of
the problem is that it's a mix of lots of boilerplate code testing for
special conditions and edge cases that is boring to write and fiddly
to get right, together with a kernel that is a pile of polynomial
evaluations full of magic numbers that needs specialist skills to
write.  If we could get someone with the relevant skills to formally
list all the special conditions & edge cases for each function, it
should be possible to generate both the library C code and test cases
from that - which would remove a lot of the tedium.

-- 
Peter Jeremy