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

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_at_gnu.org/msg26571.html

[9] http://leaf.dragonflybsd.org/mailarchive/commits/2011-12/msg00190.html