My interpretation of dput.Rd is that dput() gives an exact ASCII form of the internal representation of an R object. But: rhankin at cuttlefish:~ $ R --version R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night" Copyright (C) 2019 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) [snip] rhankin at cuttlefish:~ $ R --vanilla --quiet> x <- sum(dbinom(0:20,20,0.35)) > dput(x)1> x-1[1] -4.440892e-16> > x==1[1] FALSE>So, dput(x) gives 1, but x is not equal to 1. Can anyone advise?
Hello, FAQ 7.31 See also this StackOverflow post: https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal Hope this helps, Rui Barradas ?s 00:08 de 29/02/20, robin hankin escreveu:> My interpretation of dput.Rd is that dput() gives an exact ASCII form > of the internal representation of an R object. But: > > rhankin at cuttlefish:~ $ R --version > R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night" > Copyright (C) 2019 The R Foundation for Statistical Computing > Platform: x86_64-pc-linux-gnu (64-bit) > > [snip] > > rhankin at cuttlefish:~ $ R --vanilla --quiet >> x <- sum(dbinom(0:20,20,0.35)) >> dput(x) > 1 >> x-1 > [1] -4.440892e-16 >> >> x==1 > [1] FALSE >> > > So, dput(x) gives 1, but x is not equal to 1. Can anyone advise? > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
On 2/28/20 11:42 PM, Rui Barradas wrote:> Hello, > > FAQ 7.31 > > See also this StackOverflow post: > > https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal >That was going to be my initial response, but then I realized that the question might be why the dput representation of the x variable didn't display the detail of the decimal fraction out at the 16th or seventeenth place. So here's some further results to chew on: 1 (rather than 0.99999999999999955591) is what would get if `dput` were used to send it to a file: ?dput(x, file="temp.txt") ?x <- scan(file="temp.txt") #Read 1 item ?x==1 #[1] TRUE And if you wanted more precision with the value before it got rectified by output/input? you could use the control parameter: dput(x, control="digits17") #0.99999999999999956 HTH; David.> > Hope this helps, > > Rui Barradas > > ?s 00:08 de 29/02/20, robin hankin escreveu: >> My interpretation of dput.Rd is that dput() gives an exact ASCII form >> of the internal representation of an R object.? But: >> >> ? rhankin at cuttlefish:~ $ R --version >> R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night" >> Copyright (C) 2019 The R Foundation for Statistical Computing >> Platform: x86_64-pc-linux-gnu (64-bit) >> >> [snip] >> >> rhankin at cuttlefish:~ $ R --vanilla --quiet >>> x <- sum(dbinom(0:20,20,0.35)) >>> dput(x) >> 1 >>> x-1 >> [1] -4.440892e-16 >>> >>> x==1 >> [1] FALSE >>> >> >> So, dput(x) gives 1, but x is not equal to 1.? Can anyone advise? >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
Hi Robin, In the future, questions like this belong on R-help, not R-devel as it is a basic usage question not a discussion about development of the R language itself or similar. That said, ?dput states a number of times that exact deparsing is not always possible and that dput is not appropriate for what I'm inferring you may be trying to do with it. I would not have expected this in particular to be one of those cases, to be honest, but its within spec. dput is NOT guaranteed to give back an identical object, in fact according to the docs in some cases it should be expected not to. As for why dput is doing this , I'm not sure if its that some amount off formatting is going on inside dput, or if its a finite precision issue as suggested by Rui. I think the former is more consistent with the behavior you're seeing but I don't have time to dig into the guts of dput right this second. Either way, If you want exact recreation of the object you have you need to either run the actual code you used to generate it (on the same data in the same environment, etc etc) or serialize it out via saveRDS (or just save if you must) and then readRDS/load it back in. I hope that helps. ~G On Fri, Feb 28, 2020 at 11:43 PM Rui Barradas <ruipbarradas at sapo.pt> wrote:> Hello, > > FAQ 7.31 > > See also this StackOverflow post: > > https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal > > Hope this helps, > > Rui Barradas > > ?s 00:08 de 29/02/20, robin hankin escreveu: > > My interpretation of dput.Rd is that dput() gives an exact ASCII form > > of the internal representation of an R object. But: > > > > rhankin at cuttlefish:~ $ R --version > > R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night" > > Copyright (C) 2019 The R Foundation for Statistical Computing > > Platform: x86_64-pc-linux-gnu (64-bit) > > > > [snip] > > > > rhankin at cuttlefish:~ $ R --vanilla --quiet > >> x <- sum(dbinom(0:20,20,0.35)) > >> dput(x) > > 1 > >> x-1 > > [1] -4.440892e-16 > >> > >> x==1 > > [1] FALSE > >> > > > > So, dput(x) gives 1, but x is not equal to 1. Can anyone advise? > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
I think Robin knows about FAQ 7.31/floating point (author of
'Brobdingnag', among other numerical packages). I agree that this is
surprising (to me).
To reframe this question: is there way to get an *exact* ASCII
representation of a numeric value (i.e., guaranteeing the restored value
is identical() to the original) ?
.deparseOpts has
?"digits17"?: Real and finite complex numbers are output using
format ?"%.17g"? which may give more precision than the
default (but the output will depend on the platform and there
may be loss of precision when read back).
... but this still doesn't guarantee that all precision is kept.
Maybe
saveRDS(x,textConnection("out","w"),ascii=TRUE)
identical(x,as.numeric(out[length(out)])) ## TRUE
?
On 2020-02-29 2:42 a.m., Rui Barradas wrote:> Hello,
>
> FAQ 7.31
>
> See also this StackOverflow post:
>
> https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal
>
> Hope this helps,
>
> Rui Barradas
>
> ?s 00:08 de 29/02/20, robin hankin escreveu:
>> My interpretation of dput.Rd is that dput() gives an exact ASCII form
>> of the internal representation of an R object.? But:
>>
>> ? rhankin at cuttlefish:~ $ R --version
>> R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
>> Copyright (C) 2019 The R Foundation for Statistical Computing
>> Platform: x86_64-pc-linux-gnu (64-bit)
>>
>> [snip]
>>
>> rhankin at cuttlefish:~ $ R --vanilla --quiet
>>> x <- sum(dbinom(0:20,20,0.35))
>>> dput(x)
>> 1
>>> x-1
>> [1] -4.440892e-16
>>>
>>> x==1
>> [1] FALSE
>>>
>>
>> So, dput(x) gives 1, but x is not equal to 1.? Can anyone advise?
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel