I believe the issue is that on Windows the sqrt function when called
with a NaN does not return the same NaN, as it does on other platforms.
We have
#if (defined(_WIN32) || defined(_WIN64)) && defined(__GNUC__) && \
__GNUC__ <= 4
# define R_sqrt(x) (ISNAN(x) ? x : sqrt(x))
#else
# define R_sqrt sqrt
#endif
for implementing the SQRT opcode. I suspect this came from Duncan
Murdoch; I don't know the reason for restricting to __GNUC__ <= 4. I
seem to recall that there are other places in the code where we have
similar workarounds but I can't find them at the moment.
The builtin sqrt always pretests with ISNAN.
Best,
luke
On Mon, 14 Sep 2015, Jeroen Ooms wrote:
When building R-devel with gcc 5.2.0 (mingw-w64 v4) on Windows, make
check fails reg-tests-1b.R at the following check:
x <- c(1:2, NA)
sx <- sd(x)
!is.nan(sx)
Here 'sx' should be 'NA' but it is 'NaN'. It turns out this problem
only appears when the function is byte compiled with optimization
level 3:
mysd <- function (x, na.rm = FALSE)
sqrt(var(if (is.vector(x)) x else as.double(x), na.rm = na.rm))
mysd(x)
# [1] NA
compiler::cmpfun(mysd, list(optimize = 1L))(x)
# [1] NA
compiler::cmpfun(mysd, list(optimize = 2L))(x)
# [1] NA
compiler::cmpfun(mysd, list(optimize = 3L))(x)
# [1] NaN
The problem does not appear with gcc 5.2.0 on Debian, and also not
with gcc 4.9.3 on Windows. Where do I start debugging this? The
disassembled output from the compiled functions is here:
https://gist.github.com/jeroenooms/3206945a6db6680a9c5c
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
