>>>>> Rodrigo Zepeda <rzeped...@gmail.com> >>>>> on Fri, 17 Mar 2017 12:56:06 -0600 writes:
> Dear all, > We seem to have found a "strange" behaviour in the hyperbolic tangent > function tanh on Windows. > When running tanh(356 + 0i) the Windows result is NaN + 0.i while on Mac > the result is 1 + 0i. It doesn't seem to be a floating point error because > on Mac it is possible to run arbitrarily large numbers (say tanh( > 999999677873648767519238192348124812341234182374817239847812738481234871823+0i) > ) and still get 1 + 0i as result. This seems to be related to the imaginary > part as tanh(356) returns 1 in both Windows and Mac. > We have obtained those results in: > 1) Mac with El Capitan v 10.11.6 *processor: 2.7 GHz Intel Core i5* > - 2) Mac with Sierra v 10.12.3 *processor: 3.2 GHz Intel Core i5* > - 3) Windows 10 Home v 1607 *processor: Intel Core m3-SY30 CPU@ 0.90 GHz > 1.51 GHz* > - 4) Windows 7 Home Premium Service Pack 1 *processor: Intel Core i5-2410M > CPU @2.30 GHz 2.30GHz.* (The hardware should not matter). Yes, there is a bug here on Windows only, (several Linux versions work correctly too). > In all cases we are using R version 3.3.3 (64 bits) > - *Does anybody have a clue on why is this happening?* > PS: We have previously posted this issue in Stack Overflow ( > http://stackoverflow.com/questions/42847414/hyperbolic-tangent-in-r-throws-nan-in-windows-but-not-in-mac). > A comment suggests it is related to a glibc bug. Yes, that would have been my guess too... as indeed, R on Windows which should work for quite old versions of Windows has been using a relatively old (gcc / libc) toolchain. The upcoming version of R 3.4.0 uses a considerably newer toolchain *BUT* I've just checked the latest "R-devel" binary and the bug is still present there. Here's a slight extension of the answer I wrote to the above SO question here: http://stackoverflow.com/a/42923289/161921 ... Windows uses somewhat old C libraries, and here it is the "mathlib" part of glibc. More specifically, according to the CRAN download page for R-devel for Windows https://cran.r-project.org/bin/windows/base/rdevel.html , the R 3.3.z series uses the gcc 4.6.3 (March 2012) toolchain, whereas "R-devel", the upcoming (not yet released!) R 3.4.z series uses the gcc 4.9.3 (June 2015) toolchain. According to Ben Bolker's comment on SO, the bug in glibc should have been fixed in 2012 -- and so the change from 4.6.3 to 4.9.3 should have helped, **however* I've just checked (installed the R-devel binary from CRAN on our Windows server virtual machine) and I see that the problem is still present there: In yesterday's version of R-devel, tanh(500+0i) still returns NaN+0i. I now think a better solution would be to use R's internal substitute (in R's src/main/complex.c): There, we have ------------------------------------------------ #ifndef HAVE_CTANH #define ctanh R_ctanh static double complex ctanh(double complex z) { return -I * ctan(z * I); /* A&S 4.5.9 */ } #endif ------------------------------------------------ and we should use it (by "#undef HAVE_CTAN" (or better by a configure check, using ctanh("500 + 0i"), as I see that on Windows, R> -1i * tan((500+0i)*1i) gives [1] 1+0i as it should for tanh(500+0i) --- but does not on Windows. Martin Maechler ETH Zurich and R Core ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel