dput()

On 29/02/2020 4:19 a.m., Ben Bolker wrote:

  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.

"Using control = c("all", "hexNumeric") comes closest to making
deparse() an inverse of parse(), as representing double and complex
numbers as decimals may well not be exact. However, not all objects are
deparse-able even with this option. A warning will be issued if the
function recognizes that it is being asked to do the impossible."

   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?