[Rd] Very small numbers in hexadecimal notation parsed as zero

[Florent Angly]

Hi Martin,
Thanks for the Bugzilla account. I have filed this bug under number 17199.
Cheers,
Florent

On 21 December 2016 at 12:28, Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>>>>>> 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