[Rd] dput()

[robin hankin]

 Thanks guys, I guess I should have referred to FAQ 7.31 (which I am
indeed very familiar with) to avoid misunderstanding.  I have always
used dput() to clarify 7.31-type issues.

The description in ?dput implies [to me at any rate] that there will
be no floating-point roundoff in its output.  I hadn't realised that
'deparsing' as discussed in dput.Rd includes precision roundoff
issues.

I guess the question I should have asked is close to Ben's: "How to
force dput() to return an exact representation of a floating point
number?".  Duncan's reply is the insight I was missing: exact decimal
representation of a double might not be possible (this had not
occurred to me).  Also, Duncan's suggestion of control = c("all",
"hexNumeric") looks good and I will experiment with this.

Best wishes

Robin




On Sun, Mar 1, 2020 at 6:22 AM Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
>
> 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 using 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 using 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 using r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >> ______________________________________________
> >> R-devel using r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel