>>>>> Florent Angly <florent.an...@gmail.com> >>>>> on Tue, 20 Dec 2016 13:26:36 +0100 writes:
> Hi all, > I have noticed incorrect parsing of very small hexadecimal numbers > like "0x1.00000000d0000p-987". Such a hexadecimal representation can > can be produced by sprintf() using the %a flag. The return value is > incorrectly reported as 0 when coercing these numbers to double using > as.double()/as.numeric(), as illustrated in the three examples below: > as.double("0x1.00000000d0000p-987") # should be 7.645296e-298 > as.double("0x1.0000000000000p-1022") # should be 2.225074e-308 > as.double("0x1.f89fc1a6f6613p-974") # should be 1.23456e-293 > The culprit seems to be the src/main/util.c:R_strtod function and in > some cases, removing the zeroes directly before the 'p' leads to > correct parsing: > as.double("0x1.00000000dp-987") # 7.645296e-298, as expected > as.double("0x1.p-1022") # 2.225074e-308, as expected Yes, this looks like a bug, indeed. Similarly convincing is a simple comparison (of even less extreme) > as.double("0x1p-987") [1] 7.645296e-298 > as.double("0x1.0000000000p-987") [1] 0 > The "bug boundary" seems around here: > as.double("0x1.000000000000000000000000p-928") # fails [1] 0 > as.double("0x1p-928") [1] 4.407213e-280 > > as.double("0x1.000000000000000000000000p-927") # works [1] 8.814426e-280 but then adding more zeros before "p-927" also underflows. --> I have created an R bugzilla account for you; so you now can submit bug reports (including patch proposals to the source (hint!) ;-) Thank you, Florent! Martin ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel