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@gnu.org/msg26571.html
[9] http://leaf.dragonflybsd.org/mailarchive/commits/2011-12/msg00190.html
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
