From |uc@r @end|ng |rom |edor@project@org  Sun Jul 10 16:44:11 2022
From: |uc@r @end|ng |rom |edor@project@org (=?UTF-8?Q?I=C3=B1aki_Ucar?=)
Date: Sun, 10 Jul 2022 16:44:11 +0200
Subject: [Rd] Floating point issue
In-Reply-To: <cb4678b2d846400194e23034c6cf7674@chu-rouen.fr>
References: <CAEKh8uhNTF3RczavV-jh82tK9e=iDr2tzys=wGSk6ZD5e2tndg@mail.gmail.com>
 <25290.56745.942106.634125@rob.eddelbuettel.com>
 <cb4678b2d846400194e23034c6cf7674@chu-rouen.fr>
Message-ID: <CALEXWq3F86UV71qzWaUHrZkZb9k8dC2H_OR_cYqzvEf6pFz9hA@mail.gmail.com>

On Sun, 10 Jul 2022 at 16:28, GILLIBERT, Andre
<Andre.Gillibert at chu-rouen.fr> wrote:
>
> > No, that is how computers work (with floating point numbers).
>
>
> The fact that not all values are representable by floating point does not mean that outputing a number with maximum accuracy, then reading it back, should yield a different number.
>
>
> I would like to point that I cannot reproduce this "bug" on the official R 4.2.0 Windows x86_64 build on an AMD Ryzen 1700 on Windows 10.

I cannot reproduce this on a 64-bit Linux build of R 4.1.3 either:

options(scipen = 999)
1e24
#> [1]  999999999999999983222784
1e24 == 999999999999999983222784
#> [1] TRUE

1e25
#> [1] 10000000000000000905969664
1e25 == 10000000000000000905969664
#> [1] TRUE

10000000000000000905969664
#> [1] 10000000000000000905969664

10000000000000003053453312
#> [1] 10000000000000003053453312

10000000000000000000000000 == 1e25
#> [1] TRUE

-- 
I?aki ?car



[Rd] Floating point issue
=?UTF-8?Q?I=C3=B1aki_Ucar?=