[Rd] Floating point issue

[Antoine Fabri]

Indeed, apologies for the oversight

On Mon, 11 Jul 2022, 03:14 Bill Dunlap, <williamwdunlap using gmail.com> wrote:

> You said you got the same results as I did.  Not so, the parsing of the
> long numeric differs in the last bit of the mantissa.
>
> (A=Antoine, B=Bill):
>
> bitC(10^25)
> #A [1] 0 10001010010 | 0000100010110010101000101100001010000000001010010001
> #B [1] 0 10001010010 | 0000100010110010101000101100001010000000001010010001
>
> bitC(10000000000000000905969664)
> #A [1] 0 10001010010 | 0000100010110010101000101100001010000000001010010010
> #B [1] 0 10001010010 | 0000100010110010101000101100001010000000001010010001
>
> bitC(10000000000000000905969664 - 10^25)
> #A [1] 0 10000011110 | 0000000000000000000000000000000000000000000000000000
> #B [1] 0 00000000000 | 0000000000000000000000000000000000000000000000000000
>
> On Sun, Jul 10, 2022 at 2:39 PM Antoine Fabri <antoine.fabri using gmail.com>
> wrote:
>
>> Thanks, I get the exact same results as yours
>>
>> ``` r
>> bitC <- function(x) noquote(vapply(as.double(x), function(x) { # split
>> one double
>>   b <- substr(as.character(rev(numToBits(x))), 2L, 2L)
>>       paste0(c(b[1L], " ", b[2:12], " | ", b[13:64]), collapse = "")
>>     }, ""))
>> bitC(10^25)
>> #> [1] 0 10001010010 |
>> 0000100010110010101000101100001010000000001010010001
>> bitC(10000000000000000905969664)
>> #> [1] 0 10001010010 |
>> 0000100010110010101000101100001010000000001010010010
>> bitC(10000000000000000905969664 - 10^25)
>> #> [1] 0 10000011110 |
>> 0000000000000000000000000000000000000000000000000000
>> bitC(1e25)
>> #> [1] 0 10001010010 |
>> 0000100010110010101000101100001010000000001010010001
>> ```
>>
>> <sup>Created on 2022-07-10 by the [reprex package](
>> https://reprex.tidyverse.org) (v2.0.1)</sup>
>>
>> Le dim. 10 juil. 2022 à 22:23, Bill Dunlap <williamwdunlap using gmail.com> a
>> écrit :
>>
>>> The following function, 'bitC' from ?numToBits, displays the bits in a
>>> double precision number, separated into the sign bit, the 11 exponent bits,
>>> and the 52 bits in the mantissa.  I've shown the results with your numbers
>>> from R-2.4.0 on my Windows 11 Lenovo laptop: what do you get?
>>>
>>> > bitC <- function(x) noquote(vapply(as.double(x), function(x) { # split
>>> one double
>>> +     b <- substr(as.character(rev(numToBits(x))), 2L, 2L)
>>> +     paste0(c(b[1L], " ", b[2:12], " | ", b[13:64]), collapse = "")
>>> +   }, ""))
>>> > bitC(10^25)
>>> # [1] 0 10001010010 |
>>> 0000100010110010101000101100001010000000001010010001
>>> > bitC(10000000000000000905969664)
>>> # [1] 0 10001010010 |
>>> 0000100010110010101000101100001010000000001010010001
>>> > bitC(10000000000000000905969664 - 10^25)
>>> # [1] 0 00000000000 |
>>> 0000000000000000000000000000000000000000000000000000
>>> > bitC(1e25)
>>> # [1] 0 10001010010 |
>>> 0000100010110010101000101100001010000000001010010001
>>>
>>> -Bill
>>>
>>> On Sun, Jul 10, 2022 at 7:00 AM Antoine Fabri <antoine.fabri using gmail.com>
>>> wrote:
>>>
>>>> Dear r-devel,
>>>>
>>>> For some numbers, the printed value is not equivalent to the input :
>>>>
>>>> options(scipen = 999)
>>>> ## GOOD
>>>> 1e24
>>>> #> [1]  999999999999999983222784
>>>> 1e24 == 999999999999999983222784
>>>> #> [1] TRUE
>>>>
>>>> ## BAD
>>>> 1e25
>>>> #> [1] 10000000000000000905969664
>>>> 1e25 == 10000000000000000905969664
>>>> #> [1] FALSE
>>>>
>>>> ## STILL BAD
>>>> 10000000000000000905969664
>>>> #> [1] 10000000000000003053453312
>>>>
>>>> ## GOOD AGAIN
>>>> 10000000000000003053453312
>>>> #> [1] 10000000000000003053453312
>>>>
>>>> # Additionally
>>>> 10000000000000000000000000 == 1e25
>>>> #> [1] FALSE
>>>>
>>>> Are these bugs ?
>>>>
>>>>         [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> R-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>

	[[alternative HTML version deleted]]