On Wed, 18 Nov 2020 at 10:26, Tomas Kalibera <tomas.kalib...@gmail.com> wrote: > > On 11/17/20 9:34 PM, Bill Dunlap wrote: > > I just got a new Windows laptop (i7, 10th generation CPU), installed > > 'Windows Subsystem for Linux 2' and then installed Ubuntu 20.04 and > > used 'apt-get install' to install packages that the R build seems > > to require. In particular, I am using gcc version 9.3.0. The > > build went without a hitch but the tests showed that deparse(1e-16) > > produced "1.00000000000000e-16" instead of the expected "1e-16". > > > > It looks like the problem is in src/main/format.c:scientific(). The > > lowest two+ bytes in the fractional part of the long double (80-bit) > > return value of powl(10.0L, -30L), seem to be corrupted. I made a > > standalong program to test powl and saw no problem - it gives the > > same results for the fractional part as bc does. > > > > bc: A2425FF7 5E14FC31 A125... > > standalone: 22425FF7 5E14FC32 > > R: 22425FF7 5E151800 > > > > There are lots of other small numbers with the same problem: > > > > > > > grep(value=TRUE, "0e", > > vapply((1+(0:10000)/1000)*1e-15, deparse, "")) > > [1] "8.56000000000000e-15" "8.71700000000000e-15" "8.77800000000000e-15" > > [4] "8.93500000000000e-15" "9.50800000000000e-15" "9.83800000000000e-15" > > [7] "9.89900000000000e-15" "9.93400000000000e-15" "9.99500000000000e-15" > >> str(grep(value=TRUE, "0e", vapply((1+(0:10000)/1000)*1e-14, deparse, ""))) > > chr [1:295] "8.00200000000000e-14" "8.00500000000000e-14" ... > > > > Has anyone else seen this? I am wondering if this is an oddity in WSL2 > > > > or Ubuntu's gcc-9.3.0.
I cannot reproduce this issue (version 20H2, build 19042.630; Ubuntu 20.04 installed from the store). Are you sure you are running on WSL2? (You can check this with `wsl --list --verbose`). > Almost surely it is Windows/WSL related, I'm not seeing this on Ubuntu > 20.04. > > One thing to check might be the FPU control word. In a Windows build, R > will set as it is on Unix, to use all 80 bits when values stay in FPU > registers, which is not the Windows default. This should not matter with > SSE anymore, but maybe something is still using the FPU. This is just > using inline assembly, so one could enable it as experiment. In > principle, this could be also due to some other things specific to > Windows that R works around in Windows builds, but doesn't in Linux > builds assuming they will not run on Windows. It does run on Linux. WSL2 runs a modified version of the Linux kernel on top of Hyper-V. Unless Bill is running WSL1, which runs on top of the Windows kernel with a syscall translation layer. > Other issues I had with WSL in the past (trying to build R and run > checks) included time-zones and surprising encodings, but I didn't check > recently. I would not use R on WSL unless my goal was to diagnose these > issues and see if they could be overcome on the R side. > > Best > Tomas -- Iñaki Úcar ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
