On 18.05.2012 16:15 (UTC+1), Prof Brian Ripley wrote:
On 15/05/2012 20:45, Rainer Hurling wrote:
On 15.05.2012 20:49 (UTC+1), Murray Stokely wrote:
On Tue, May 15, 2012 at 10:05 AM, Rainer Hurling<rhur...@gwdg.de> wrote:
About April 25th, there had been some changes within R-devel's
src/nmath/pnbeta.c (and probably some other relevant places) and now
building R-devel on FreeBSD 10.0-CURRENT (amd64) with gcc-4.6.4 and
math/R-devel (selfmade forked port from math/R) fails like this:
It seems, that at least one new C99 function (log1pl) is introduced in
R-devel, see
src/nmath/pnbeta.c:l95
return (double) (log_p ? log1pl(-ans) : (1 - ans));
AFAIK, Bruce Evans is not happy with the numerical accuracy of other
open-source implementations of log1pl and so has blocked their
inclusion in FreeBSD pending work on a better implementation.
Can you put a conditional FreeBSD check here and use log1p instead of
log1pl instead as a workaround?
I can admire the insistence on correctness from the FreeBSD libm
maintainers for their technical purity, but it can be a bit of a pain
for things like this.
- Murray
I read about this discussion and in principle I concur with your
opinion. As a scientist I tend to expect greatest possible correctness
from a statistical routine, especially when it uses long double format.
As a quick and dirty workaround I applied the following patch:
--- src/nmath/pnbeta.c.orig 2012-04-25 17:55:14.000000000 +0200
+++ src/nmath/pnbeta.c 2012-05-15 20:58:26.000000000 +0200
@@ -92,7 +92,11 @@
else {
if(ans > 1 - 1e-10) ML_ERROR(ME_PRECISION, "pnbeta");
if (ans > 1.0) ans = 1.0; /* Precaution */
+#if !defined(__FreeBSD__)
return (double) (log_p ? log1pl(-ans) : (1 - ans));
+#else
+ return (double) (log_p ? log1p(-ans) : (1 - ans));
+#endif /* FreeBSD */
}
}
It builds and installs fine now and I hope there are no side effects ...
Note though that R has *required* C99 compliance for quite a while, and
that is not now even the current C standard. Using an OS that fails to
comply to a 12-year-old standard is your own choice ... and you get the
choice of using an equally old version of R.
Of course you are right with C99 compliance on FreeBSD. It is a long
outstanding issue to get these long double functions in.
For me personally there are *many* reasons to use FreeBSD and at the
moment R is one of only very few software packages we have serious
trouble with C99 functions.
As you know, using an old version of R is not a real options. Because of
that, we are looking at R-devel to find problems with FreeBSD in good time.
I've added log1pl to the depressing list of FreeBSD workarounds:
untested as I currently don't have access to a FreeBSD setup.
Many thanks for the patch. I built it and it is much more elegant than
my workaround (HAVE_LOG1PL, log1p with double). And yes, the list is
depressing.
However, I think this has to come to an end: if a project such as
Mingw-w64 can make the effort to supply a great deal of the C99
functions missing from their OS then we must expect FreeBSD to do likewise.
As I said before, I agree with this point of view. But I am not a
developer and a am not standing for the FreeBSD project. I am only an
interested user and a maintainer for a few small FreeBSD ports
(adaptions of third party software).
I will ask the FreeBSD people again for better C99 compliance ...
I really appreciate your help on this annoying issues and hope we will
find a solution on FreeBSD in the near future.
Regards,
Rainer Hurling
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
