Yesterday r236148 (Allow inclusion of libc++ <cmath> to work after
including math.h) was comitted to head, many thanks. Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now "really implemented"? As far as I understand, they had only been declared before? If this is right, are they usable on a recent CURRENT, built with gcc42 (system compiler), by ports which use gcc46 (not clang)? If not, are there any plans to implement these functions in the near future? The use of C99 extra long double functions would be of interest for example for programs like math/R, especially its upcoming releases. Many thanks for any clarification. Regards, Rainer Hurling _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
On 28 May 2012, at 05:35, Rainer Hurling wrote:
> Yesterday r236148 (Allow inclusion of libc++ <cmath> to work after including math.h) was comitted to head, many thanks. > > Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now "really implemented"? As far as I understand, they had only been declared before? They are still not implemented. The <cmath> header in libc++ provides wrappers around these functions for C++, but if they are not declared then the compiler throws an error. Now there is a linker error if they are used, but if they are not used then it works irrespective of whether you just include <cmath> or do undefined things like include <math.h> first. > If this is right, are they usable on a recent CURRENT, built with gcc42 (system compiler), by ports which use gcc46 (not clang)? If not, are there any plans to implement these functions in the near future? I think they're one of the last bits of C99 / C11 that anyone actually cares about (C11 unicode support being another), so they'll probably get done at some point, but doing them correctly is nontrivial, except on platforms where double and long double are the same. > The use of C99 extra long double functions would be of interest for example for programs like math/R, especially its upcoming releases. I would be very wary of anything that depends on long double. The C spec makes no constraints on the range of float, double, or long double, but by convention on most platforms float is an IEEE 754 32-bit floating point value and double is 64-bit. No such conventions apply to long doubles and I know of (widely deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively. I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even though the platform ABI spec recommends using 128 bits. x86 uses 80-bit x87 values (although sizeof(long double) may be 16 because they have some padding bytes in memory). If your program is tolerant of a potential variation in precision between 64 bits and 128 bits, then it is probably tolerant of just using doubles. David_______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:
> On 28 May 2012, at 05:35, Rainer Hurling wrote: First I should note that I am by no means an expert in C / C++ or C99 standards. So my comments are only on a level of someone who is using FreeBSD for scientific purposes like GIS and math applications and who is the maintainer of some scientific ports (like math/saga). >> Yesterday r236148 (Allow inclusion of libc++<cmath> to work after including math.h) was comitted to head, many thanks. >> >> Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now "really implemented"? As far as I understand, they had only been declared before? > > They are still not implemented. The<cmath> header in libc++ provides wrappers around these functions for C++, but if they are not declared then the compiler throws an error. Now there is a linker error if they are used, but if they are not used then it works irrespective of whether you just include<cmath> or do undefined things like include<math.h> first. Ok, that's what I had supposed. Because the main difference between r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of binning? >> If this is right, are they usable on a recent CURRENT, built with gcc42 (system compiler), by ports which use gcc46 (not clang)? If not, are there any plans to implement these functions in the near future? > > I think they're one of the last bits of C99 / C11 that anyone actually cares about (C11 unicode support being another), so they'll probably get done at some point, but doing them correctly is nontrivial, except on platforms where double and long double are the same. Yes, I agree. These outstanding long double math functions (like log1pl) and better unicode support are really needed for some important third party projects like R or SAGA GIS. In the past I have read several times discussions about the correctness of long double functions on FreeBSD. Some drafts have been dismissed because of there inaccuracy in special cases. Also was discussed to get missing libm routines from NetBSD [1]. It appears as if we have to wait some more time ... >> The use of C99 extra long double functions would be of interest for example for programs like math/R, especially its upcoming releases. > > I would be very wary of anything that depends on long double. The C spec makes no constraints on the range of float, double, or long double, but by convention on most platforms float is an IEEE 754 32-bit floating point value and double is 64-bit. No such conventions apply to long doubles and I know of (widely deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively. I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even though the platform ABI spec recommends using 128 bits. x86 uses 80-bit x87 values (although sizeof(long double) may be 16 because they have some padding bytes in memory). If your program is tolerant of a potential variation in precision between 64 bits and 128 bits, then it is probably tolerant of just using doubles. Yes, I think in most cases math/R is tolerant enough of just using doubles. But in the near future they plan to implement much more of the C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. So these problems will increase :-( Many thanks for your fast und well explained answer, I really appreciate it. Rainer > David [1] http://lists.freebsd.org/pipermail/freebsd-standards/2011-February/002119.html [2] https://stat.ethz.ch/pipermail/r-devel/2012-May/064128.html And some more places I found interesting about C99 and FreeBSD [3] http://www.freebsd.org/projects/c99/index.html [4] http://wiki.freebsd.org/MissingMathStuff [5] http://marc.info/?l=freebsd-standards&m=123158761305427 [6] http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028030.html [7] http://www.koders.com/c/fid164FD2F50C9AAA63119A641875824455B3AE6B55.aspx?s=log1pl.c [8] http://www.mail-archive.com/bug-gnulib@.../msg26571.html [9] http://leaf.dragonflybsd.org/mailarchive/commits/2011-12/msg00190.html _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
On 28 May 2012, at 13:30, Rainer Hurling wrote:
> On 28.05.2012 10:41 (UTC+1), David Chisnall wrote: >> On 28 May 2012, at 05:35, Rainer Hurling wrote: > > Ok, that's what I had supposed. Because the main difference between r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of binning? Yes, it's just about making libc++'s cmath header compile, nothing more. > Yes, I agree. These outstanding long double math functions (like log1pl) and better unicode support are really needed for some important third party projects like R or SAGA GIS. I very much doubt that anything is using the C11 unicode stuff yet, since no compiler or libc currently supports it... > In the past I have read several times discussions about the correctness of long double functions on FreeBSD. Some drafts have been dismissed because of there inaccuracy in special cases. Also was discussed to get missing libm routines from NetBSD [1]. It appears as if we have to wait some more time ... I thought we did pull in some NetBSD libm stuff recently. Not sure what the status of that is, you'd need to check with das@. > Yes, I think in most cases math/R is tolerant enough of just using doubles. But in the near future they plan to implement much more of the C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. So these problems will increase :-( Reading that email, it seems that they would prefer a function that exists and returns the wrong result to one that does not exist. If this is really the attitude of the developers of R, then I shall make absolutely certain that I avoid using R for anything where I actually care about the results, and would strongly encourage everyone else to do the same. In general, (sane) people use the long double versions because they need the extra precision and care about the result. We could easily implement the long double versions now as toy versions that just called the double versions, but that would upset a lot of people who actually care about accuracy, who are the main target audience for these functions. David_______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
On 28.05.2012 14:49 (UTC+1), David Chisnall wrote:
> On 28 May 2012, at 13:30, Rainer Hurling wrote: > >> On 28.05.2012 10:41 (UTC+1), David Chisnall wrote: >>> On 28 May 2012, at 05:35, Rainer Hurling wrote: >> >> Ok, that's what I had supposed. Because the main difference between r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of binning? > > Yes, it's just about making libc++'s cmath header compile, nothing more. I see, thanks. >> Yes, I agree. These outstanding long double math functions (like log1pl) and better unicode support are really needed for some important third party projects like R or SAGA GIS. > > I very much doubt that anything is using the C11 unicode stuff yet, since no compiler or libc currently supports it... Of course you are right with C11 unicode stuff. I thougt more about my actual problems to get the right charset conversions between different apps, i.e. qgis <-> wxgtk29 <-> saga gis. Or using Gnome apps (utf8) on windowmaker using ISO8859-15. But this is OT here, sorry. >> In the past I have read several times discussions about the correctness of long double functions on FreeBSD. Some drafts have been dismissed because of there inaccuracy in special cases. Also was discussed to get missing libm routines from NetBSD [1]. It appears as if we have to wait some more time ... > > I thought we did pull in some NetBSD libm stuff recently. Not sure what the status of that is, you'd need to check with das@. I am not aware of it and will have a look. But this did not implement the missing long double functions. >> Yes, I think in most cases math/R is tolerant enough of just using doubles. But in the near future they plan to implement much more of the C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. So these problems will increase :-( > > Reading that email, it seems that they would prefer a function that exists and returns the wrong result to one that does not exist. If this is really the attitude of the developers of R, then I shall make absolutely certain that I avoid using R for anything where I actually care about the results, and would strongly encourage everyone else to do the same. This was a statement of just one (though not unimportant) person from the R Core team. I don't think that this is the only view of R Core developers. On the other hand he is the person, who actually did most of the stuff within R for years now to circumvent the problems running on FreeBSD. > In general, (sane) people use the long double versions because they need the extra precision and care about the result. We could easily implement the long double versions now as toy versions that just called the double versions, but that would upset a lot of people who actually care about accuracy, who are the main target audience for these functions. It seems to be a general trend (outside of FreeBSD) to implement more and more stuff at the cost of quality. I am certain that for many FreeBSD users accuracy is more important than completeness, especially for scientists. Nevertheless this policy brings some problems in the real world ;-) Thanks again for your thoughts, Rainer > David _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
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. Stephen _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
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? -- Steve _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Montgomery-Smith, Stephen
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) Download Attachment |
In reply to this post by Steve Kargl
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? _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
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 attachment0 (203 bytes) Download Attachment |
In reply to this post by Montgomery-Smith, Stephen
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. -- Steve _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Peter Jeremy-8
On Tue, May 29, 2012 at 08:04:36AM +1000, Peter Jeremy wrote:
> 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. Given that cephes was written years before C99 was even conceived, I suspect all functions are sub-standard. 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. 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. -- Steve _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Peter Jeremy-8
On Tue, May 29, 2012 at 07:05:07AM +1000, Peter Jeremy wrote:
> 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." Please talk to das@ (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. -- Steve _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Steve Kargl
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.) _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
On Mon, May 28, 2012 at 06:03:37PM -0500, Stephen Montgomery-Smith wrote:
> 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? Search the llvm and gcc bug databases, I'm the person that informed both that they can't deal with complex arithematic correctly. Interesting that you mention ccosh. >From clog.c in http://www.netlib.org/cephes/cmath.tgz void ccosh (z, w) cmplx *z, *w; { double x, y; x = z->r; y = z->i; w->r = cosh (x) * cos (y); w->i = sinh (x) * sin (y); } >From clog.c in http://www.netlib.org/cephes/c9x-complex double complex ccosh (z) double complex z; { double complex w; double x, y; x = creal(z); y = cimag(z); w = cosh (x) * cos (y) + (sinh (x) * sin (y)) * I; return (w); } See math_private.h about the above. And, finally, : /*- * Copyright (c) 2005 Bruce D. Evans and Steven G. Kargl * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice unmodified, this list of conditions, and the following * disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ /* * Hyperbolic cosine of a complex argument z = x + i y. * * cosh(z) = cosh(x+iy) * = cosh(x) cos(y) + i sinh(x) sin(y). * * Exceptional values are noted in the comments within the source code. * These values and the return value were taken from n1124.pdf. */ #include <sys/cdefs.h> __FBSDID("$FreeBSD: head/lib/msun/src/s_ccosh.c 226599 2011-10-21 06:29:32Z das $"); #include <complex.h> #include <math.h> #include "math_private.h" static const double huge = 0x1p1023; double complex ccosh(double complex z) { double x, y, h; int32_t hx, hy, ix, iy, lx, ly; x = creal(z); y = cimag(z); EXTRACT_WORDS(hx, lx, x); EXTRACT_WORDS(hy, ly, y); ix = 0x7fffffff & hx; iy = 0x7fffffff & hy; /* Handle the nearly-non-exceptional cases where x and y are finite. */ if (ix < 0x7ff00000 && iy < 0x7ff00000) { if ((iy | ly) == 0) return (cpack(cosh(x), x * y)); if (ix < 0x40360000) /* small x: normal case */ return (cpack(cosh(x) * cos(y), sinh(x) * sin(y))); /* |x| >= 22, so cosh(x) ~= exp(|x|) */ if (ix < 0x40862e42) { /* x < 710: exp(|x|) won't overflow */ h = exp(fabs(x)) * 0.5; return (cpack(h * cos(y), copysign(h, x) * sin(y))); } else if (ix < 0x4096bbaa) { /* x < 1455: scale to avoid overflow */ z = __ldexp_cexp(cpack(fabs(x), y), -1); return (cpack(creal(z), cimag(z) * copysign(1, x))); } else { /* x >= 1455: the result always overflows */ h = huge * x; return (cpack(h * h * cos(y), h * sin(y))); } } /* * cosh(+-0 +- I Inf) = dNaN + I sign(d(+-0, dNaN))0. * The sign of 0 in the result is unspecified. Choice = normally * the same as dNaN. Raise the invalid floating-point exception. * * cosh(+-0 +- I NaN) = d(NaN) + I sign(d(+-0, NaN))0. * The sign of 0 in the result is unspecified. Choice = normally * the same as d(NaN). */ if ((ix | lx) == 0 && iy >= 0x7ff00000) return (cpack(y - y, copysign(0, x * (y - y)))); /* * cosh(+-Inf +- I 0) = +Inf + I (+-)(+-)0. * * cosh(NaN +- I 0) = d(NaN) + I sign(d(NaN, +-0))0. * The sign of 0 in the result is unspecified. */ if ((iy | ly) == 0 && ix >= 0x7ff00000) { if (((hx & 0xfffff) | lx) == 0) return (cpack(x * x, copysign(0, x) * y)); return (cpack(x * x, copysign(0, (x + x) * y))); } /* * cosh(x +- I Inf) = dNaN + I dNaN. * Raise the invalid floating-point exception for finite nonzero x. * * cosh(x + I NaN) = d(NaN) + I d(NaN). * Optionally raises the invalid floating-point exception for finite * nonzero x. Choice = don't raise (except for signaling NaNs). */ if (ix < 0x7ff00000 && iy >= 0x7ff00000) return (cpack(y - y, x * (y - y))); /* * cosh(+-Inf + I NaN) = +Inf + I d(NaN). * * cosh(+-Inf +- I Inf) = +Inf + I dNaN. * The sign of Inf in the result is unspecified. Choice = always +. * Raise the invalid floating-point exception. * * cosh(+-Inf + I y) = +Inf cos(y) +- I Inf sin(y) */ if (ix >= 0x7ff00000 && ((hx & 0xfffff) | lx) == 0) { if (iy >= 0x7ff00000) return (cpack(x * x, x * (y - y))); return (cpack((x * x) * cos(y), x * sin(y))); } /* * cosh(NaN + I NaN) = d(NaN) + I d(NaN). * * cosh(NaN +- I Inf) = d(NaN) + I d(NaN). * Optionally raises the invalid floating-point exception. * Choice = raise. * * cosh(NaN + I y) = d(NaN) + I d(NaN). * Optionally raises the invalid floating-point exception for finite * nonzero y. Choice = don't raise (except for signaling NaNs). */ return (cpack((x * x) * (y - y), (x + x) * (y - y))); } And, one gets ccos for free. double complex ccos(double complex z) { /* ccos(z) = ccosh(I * z) */ return (ccosh(cpack(-cimag(z), creal(z)))); } > 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). 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! It took me 3+ years to get sqrtl() into libm, but bde and das (and myself) wanted to make sure the code worked. > 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.) I haven't looked at glibc code in years, because I hack on libm when I can. I do not want to run into questions about whether my code is tainted by the gpl. -- Steve _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
On 05/28/2012 06:30 PM, Steve Kargl wrote:
> >> From clog.c in http://www.netlib.org/cephes/c9x-complex > > double complex > ccosh (z) > double complex z; > { > double complex w; > double x, y; > > x = creal(z); > y = cimag(z); > w = cosh (x) * cos (y) + (sinh (x) * sin (y)) * I; > return (w); > } > > See math_private.h about the above. > I looked in math_private.h - I presume you meant lib/msun/src/math_private.h. I wasn't able to find anything about ccosh there. I think that for a rough and ready ccosh, this is high enough quality for a math/cephes port. I do agree that it might not be high enough quality to make FreeBSD base. (Although I don't think I have ever been in a situation where I would have been tripped up by a transcendental function that responded incorrectly to exceptional input.) > And, finally, Yes, it is very nice. > > 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! It took > me 3+ years to get sqrtl() into libm, but bde and das (and > myself) wanted to make sure the code worked. Fair enough if we are talking about the base system. > I haven't looked at glibc code in years, because I hack on libm > when I can. I do not want to run into questions about whether > my code is tainted by the gpl. > They had similar lists of exceptions. _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
On Mon, May 28, 2012 at 06:44:42PM -0500, Stephen Montgomery-Smith wrote:
> On 05/28/2012 06:30 PM, Steve Kargl wrote: > > > > >>From clog.c in http://www.netlib.org/cephes/c9x-complex > > > >double complex > >ccosh (z) > > double complex z; > >{ > > double complex w; > > double x, y; > > > > x = creal(z); > > y = cimag(z); > > w = cosh (x) * cos (y) + (sinh (x) * sin (y)) * I; > > return (w); > >} > > > >See math_private.h about the above. > > > > I looked in math_private.h - I presume you meant > lib/msun/src/math_private.h. I wasn't able to find anything about ccosh > there. > > I think that for a rough and ready ccosh, this is high enough quality > for a math/cephes port. That's the problem. It is not acceptable (imo). The comment in math_private.h that is relevant is /* * Inline functions that can be used to construct complex values. * * The C99 standard intends x+I*y to be used for this, but x+I*y is * currently unusable in general since gcc introduces many overflow, * underflow, sign and efficiency bugs by rewriting I*y as * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product. * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted * to -0.0+I*0.0. */ Those wrong +-0 mean you may up end up on the worng riemann sheet, and that NaN propagates. -- Steve _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
On 05/28/2012 07:07 PM, Steve Kargl wrote:
> On Mon, May 28, 2012 at 06:44:42PM -0500, Stephen Montgomery-Smith wrote: >> On 05/28/2012 06:30 PM, Steve Kargl wrote: >> >>> >>> > From clog.c in http://www.netlib.org/cephes/c9x-complex >>> >>> double complex >>> ccosh (z) >>> double complex z; >>> { >>> double complex w; >>> double x, y; >>> >>> x = creal(z); >>> y = cimag(z); >>> w = cosh (x) * cos (y) + (sinh (x) * sin (y)) * I; >>> return (w); >>> } >>> >>> See math_private.h about the above. >>> >> >> I looked in math_private.h - I presume you meant >> lib/msun/src/math_private.h. I wasn't able to find anything about ccosh >> there. >> >> I think that for a rough and ready ccosh, this is high enough quality >> for a math/cephes port. > > That's the problem. It is not acceptable (imo). The comment in > math_private.h that is relevant is > > /* > * Inline functions that can be used to construct complex values. > * > * The C99 standard intends x+I*y to be used for this, but x+I*y is > * currently unusable in general since gcc introduces many overflow, > * underflow, sign and efficiency bugs by rewriting I*y as > * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product. > * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted > * to -0.0+I*0.0. > */ > > Those wrong +-0 mean you may up end up on the worng riemann sheet, > and that NaN propagates. > OK, I agree with you that gcc fails to be C99 compliant. But I disagree with you that this is a big deal. 1. By being so picky about being so precise, FreeBSD is behind the time line in rolling out a usable set of C99 functions. The compilers and operating systems have many bugs, and if we waited until we were totally sure that all the bugs were gone, we wouldn't have any operating system to work with at all. Why be more picky with floating point arithmetic than the other aspects of FreeBSD? 2. If I was really worried about being on the correct Riemann sheet, I would code very, very carefully, and not rely on numerical accuracy of any kind of floating point calculation. There is a certain mathematical inconsistency in introducing 0, -0 and Inf+I*Inf, and the number of times programmers really want a very specific kind of behavior for exceptions is so rare that they are better off writing their own wrapper code than relying on any library functions. (For example, is there a difference between 0 and +0? If not, does -(0) compute to 0 or -0? I can see circumstances where I sometimes want one, and sometimes the other.) 3. But to counter my own argument, it highly bothers me that in C that "(-5)%3" evaluates to "-2" and not to "1". That bug^H^H^H feature has truly bitten me. And I have had lengthy arguments online with some C experts as to why "1" should be the correct answer, without being able to convince them. If it were up to me, the whole of the C standard would be scrapped, and rewritten with everything exactly the same except for this one thing. But to those I argued with, I seem just as picky as you seem when you insist that 0 and -0 are different. So what do I do? I live with it, just like we all live in an imperfect world. If I had a choice between correcting the C standard for "%" or solving world hunger, I would definitely settle for the second. And maybe the C programming language, for all its imperfections, has helped push frontiers of technology sufficiently that someone is less hungry than they would have otherwise been. And if those resources used to feed people had been redirected to fix the C standard, then maybe a few more people would be hungry. 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. _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
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 attachment0 (203 bytes) Download Attachment |
On Tue, May 29, 2012 at 02:56:13PM +1000, Peter Jeremy wrote:
> On 2012-May-28 15:54:06 -0700, Steve Kargl <[hidden email]> wrote: > > 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. I can't point you to test code. When I work on a function, I write test code. > > 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. sqrtl() is a bit special in that IEEE 754 requires that it have no more than 0.5 ULP for all arguments in all roundng modes. As to other functions, I've been trying for 10+ years to get some of these into FreeBSD. I can assure you that there has never been a rush of people volunteering to help or a rush of people willing to fund the development of the necessary code. > > 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. It seems you've had "a couple of years" to implement one or more of the missing functions. Yes, we'll all be dead before libm is C99 ready because no one, other than bde@, das@ and myself, has been willing to actually help write the code. I know that at least one of those three people has had no time in the last year or two work on libm. -- Steve _______________________________________________ [hidden email] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[hidden email]" |
Free forum by Nabble | Edit this page |