[Rd] Floating point issue

[Bill Dunlap]

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]]