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.* 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. Thanks, Rod [[alternative HTML version deleted]] ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel |
>>>>> Rodrigo Zepeda <[hidden email]>
>>>>> 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 ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel |
On 21.03.2017 10:54, Martin Maechler wrote: >>>>>> Rodrigo Zepeda <[hidden email]> >>>>>> 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. Actually the R-3.3.z series already uses gcc-4.9.3. Best, Uwe Ligges > > 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 > > ______________________________________________ > [hidden email] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel |
In reply to this post by Rodrigo Zepeda
This looks like a bug in mingw-w64 CRT. The problem can be produced
with C++ without R: #include <iostream> #include <cmath> #include <complex> int main(){ std::cout << std::fixed; std::complex<double> z(356, 0); std::cout << "tanh" << z << " = " << std::tanh(z) << " (tanh(356) = " << std::tanh(356) << ")\n"; } On OS-X we get: tanh(356.000000,0.000000) = (1.000000,-0.000000) (tanh(356) = 1.000000) But on Windows we get: tanh(356.000000,0.000000) = (nan,0.000000) (tanh(356) = 1.000000) I was also able to reproduce the problem with gcc 6.3 in msys2 so it has not been fixed upstream. You should file a bug report for mingw-w64. FWIF, we have run into NaN edge-case bugs before with mingw-w64. - https://sourceforge.net/p/mingw-w64/mingw-w64/ci/6617ebd5fc6b790c80071d5b1d950e737fc670e1/ - https://github.com/wch/r-source/commit/e9aaf8fdeddf27c2a9078cd214a41475c8ff6f40 I am cc'ing Ray Donnelly who is an expert on mingw-w64. ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel |
For future reference:
https://sourceforge.net/p/mingw-w64/mailman/message/35747206/ On Wed, Mar 22, 2017 at 2:12 PM, Jeroen Ooms <[hidden email]> wrote: > This looks like a bug in mingw-w64 CRT. The problem can be produced > with C++ without R: > > #include <iostream> > #include <cmath> > #include <complex> > > int main(){ > std::cout << std::fixed; > std::complex<double> z(356, 0); > std::cout << "tanh" << z << " = " << std::tanh(z) > << " (tanh(356) = " << std::tanh(356) << ")\n"; > } > > On OS-X we get: > > tanh(356.000000,0.000000) = (1.000000,-0.000000) (tanh(356) = 1.000000) > > But on Windows we get: > > tanh(356.000000,0.000000) = (nan,0.000000) (tanh(356) = 1.000000) > > I was also able to reproduce the problem with gcc 6.3 in msys2 so it > has not been fixed upstream. You should file a bug report for > mingw-w64. > > FWIF, we have run into NaN edge-case bugs before with mingw-w64. > > - https://sourceforge.net/p/mingw-w64/mingw-w64/ci/6617ebd5fc6b790c80071d5b1d950e737fc670e1/ > - https://github.com/wch/r-source/commit/e9aaf8fdeddf27c2a9078cd214a41475c8ff6f40 > > I am cc'ing Ray Donnelly who is an expert on mingw-w64. ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel |
On Mon, Mar 27, 2017 at 12:33 PM, Jeroen Ooms <[hidden email]> wrote:
> For future reference: > https://sourceforge.net/p/mingw-w64/mailman/message/35747206/ > > On Wed, Mar 22, 2017 at 2:12 PM, Jeroen Ooms <[hidden email]> wrote: > > This looks like a bug in mingw-w64 CRT. The problem can be produced > > with C++ without R: > > > > #include <iostream> > > #include <cmath> > > #include <complex> > > > > int main(){ > > std::cout << std::fixed; > > std::complex<double> z(356, 0); > > std::cout << "tanh" << z << " = " << std::tanh(z) > > << " (tanh(356) = " << std::tanh(356) << ")\n"; > > } > > > > On OS-X we get: > > > > tanh(356.000000,0.000000) = (1.000000,-0.000000) (tanh(356) = 1.000000) > > > > But on Windows we get: > > > > tanh(356.000000,0.000000) = (nan,0.000000) (tanh(356) = 1.000000) > > > > I was also able to reproduce the problem with gcc 6.3 in msys2 so it > > has not been fixed upstream. You should file a bug report for > > mingw-w64. > > > > FWIF, we have run into NaN edge-case bugs before with mingw-w64. > > > > - https://sourceforge.net/p/mingw-w64/mingw-w64/ci/ > 6617ebd5fc6b790c80071d5b1d950e737fc670e1/ > > - https://github.com/wch/r-source/commit/e9aaf8fdeddf27c2a9078cd214a414 > 75c8ff6f40 > > > > I am cc'ing Ray Donnelly who is an expert on mingw-w64. > Thanks for reporting this Jeroen. Hopefully Doug will take a look sometime soon. [[alternative HTML version deleted]] ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel |
Free forum by Nabble | Edit this page |