Very small numbers in hexadecimal notation parsed as zero

Florent Angly <florent.angly at 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