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
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]]
Hello, R 4.2.1 on Windows 11, sessionInfo() at end. I cannot reproduce this either. op <- options(scipen = 999) 1e24 # [1] 999999999999999983202404 1e24 == 999999999999999983222784 # [1] TRUE 1e25 # [1] 10000000000000000906640224 1e25 == 10000000000000000905969664 # [1] TRUE 10000000000000000905969664 # [1] 10000000000000000906640224 10000000000000003053453312 # [1] 10000000000000003053648442 10000000000000000000000000 == 1e25 # [1] TRUE options(op) sessionInfo() R version 4.2.1 (2022-06-23 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 22000) Matrix products: default locale: [1] LC_COLLATE=Portuguese_Portugal.utf8 LC_CTYPE=Portuguese_Portugal.utf8 [3] LC_MONETARY=Portuguese_Portugal.utf8 LC_NUMERIC=C [5] LC_TIME=Portuguese_Portugal.utf8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.2.1 Hope this helps, Rui Barradas ?s 15:44 de 10/07/2022, I?aki Ucar escreveu:> 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 >