From @nto|ne@|@br| @end|ng |rom gm@||@com  Sun Jul 10 17:43:03 2022
From: @nto|ne@|@br| @end|ng |rom gm@||@com (Antoine Fabri)
Date: Sun, 10 Jul 2022 17:43:03 +0200
Subject: [Rd] Floating point issue
In-Reply-To: <CALEXWq3F86UV71qzWaUHrZkZb9k8dC2H_OR_cYqzvEf6pFz9hA@mail.gmail.com>
References: <CAEKh8uhNTF3RczavV-jh82tK9e=iDr2tzys=wGSk6ZD5e2tndg@mail.gmail.com>
 <25290.56745.942106.634125@rob.eddelbuettel.com>
 <cb4678b2d846400194e23034c6cf7674@chu-rouen.fr>
 <CALEXWq3F86UV71qzWaUHrZkZb9k8dC2H_OR_cYqzvEf6pFz9hA@mail.gmail.com>
Message-ID: <CAEKh8ujbqCpL8Dv8OiB0LtHFsk+80gxU4ivPoqRKbLdfJLKc_A@mail.gmail.com>

He is my session info :

R version 4.1.3 (2022-03-10)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Monterey 12.0.1

Le dim. 10 juil. 2022 ? 16:44, I?aki Ucar <iucar at fedoraproject.org> a
?crit :

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

	[[alternative HTML version deleted]]



[Rd] Floating point issue
Antoine Fabri