On 17 November 2020 at 12:34, 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.00e-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:1)/1000)*1e-15, deparse, ""))
| [1] "8.56e-15" "8.717000e-15" "8.778000e-15"
| [4] "8.935000e-15" "9.508000e-15" "9.838000e-15"
| [7] "9.899000e-15" "9.934000e-15" "9.995000e-15"
| > str(grep(value=TRUE, "0e", vapply((1+(0:1)/1000)*1e-14, deparse, "")))
| chr [1:295] "8.002000e-14" "8.005000e-14" ...
|
| Has anyone else seen this? I am wondering if this is an oddity in WSL2
|
| or Ubuntu's gcc-9.3.0.
Plain Ubuntu 20.04.1 here, current. No issue:
> str(grep(value=TRUE, "0e", vapply((1+(0:1)/1000)*1e-14, deparse, "")))
chr(0)
>
I made sure to start R as `R --vanilla` to not have anything in my dotfiles
affect printing.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
