Use of C99 extra long double math functions after r236148
Locked
12345
12345
 
|
|
|
|
|
|
|
|
|
|
|
In reply to this post by Stephen Montgomery-Smith-3
On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith <[hidden email]> 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." -- Peter Jeremy |
attachment0 (203 bytes) |
|
|
|
In reply to this post by Steve Kargl
On 2012-May-28 13:31:59 -0700, Steve Kargl <[hidden email]> 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. ... >This is a horrible, horrible, horrible idea. Have you >looked at the cephes code, particularly the complex.h >functions? The cephes code is somewhat a mess layout-wise. Algorithmetically, it seems somewhat variable - some functions are implemented (hopefully correctly) using semi-numerical techniques, whereas others just use mathematical identities which will result in precision loss - though most of the functions include accuracy information. I agree it would be far preferable to have a properly validated C99 libm with all functions having maximum errors of a no more than a few LSB over their complete domain, as well as correct support for signed zeroes, infinities and signalling and non-signalling NaNs but that is a non-trivial undertaking. In the interim, how should FreeBSD handle apps that want a C99 libm? 1) Fail to build them 2) Provide possibly imperfect fallbacks for the unimplemented bits. If someone (I don't have the expertise) wants to identify the cephes functions that are sub-standard, we can include link-time warnings (as done for eg gets(3)) when they are used. -- Peter Jeremy |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On 2012-May-28 15:54:06 -0700, Steve Kargl <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 |
|
|
Loading...
| Powered by Nabble | Edit this page |