[Rd] dput()
Duncan Murdoch
murdoch@dunc@n @end|ng |rom gm@||@com
Mon Mar 2 10:43:53 CET 2020
On 02/03/2020 3:24 a.m., Martin Maechler wrote:
>>>>>> robin hankin
>>>>>> on Sun, 1 Mar 2020 09:26:24 +1300 writes:
>
> > 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.
>
> This was not Duncan's suggestion but rather Duncan's *citation* :
> Note that he used " .... " !
>
> The citation is from ?deparseOpts (to which one is pointed when reading ?dput),
> <rant>
> but unfortunately many people nowadays have stopped reading texts
> that are longer than a tweet... ;-)
> <rant/>
> ... and indeed, ?dput and ?deparse use 'control = "all"'
> instead of c("all", "hexNumeric") when talking about getting
> close to an inverse of parse()
>
> As a matter of fact, within R Core we had discussed this, many
> moons ago and actually had more or less decided to make "all"
> to *include* "digits17".
>
> "digits17" is "almost always" (I'm sorry I cannot quantify the
> 'almost' here) sufficient ... and is obviously conflicting with
> using hexadecimals instead of digits.
>
> For R 4.0.0, I think we should finally consider doing something
> here :
>
> 1) define "all" to include "digits17"
> so new "all" is current c("all", "digits17")
> {in a way such that c("all", "hexNumeric") implicitly removes
> "digits17" (as it's in contradiction with "hexNumeric").
>
> 2) add a new option "AllHex" := c("all", "hexNumeric"),
> (Note the capital "A": such that match.arg()-like abbreviation
> of .deparseOpts() arguments remain possible and notably "all"
> does not suddenly become ambiguous)
>
> Of course, '1)' is well possible without '2)',
> but '2)' would allow to use dput(*, control = "All")
> which is somewhat easier to readers & writers.
I think 1) is a good idea, and adding something with the meaning of
AllHex seems useful: but that's not a name I'd choose, since it's not
consistent with the other names (which are almost all camelCase). I'd
choose something like "exact" (even though it isn't :-).
Duncan Murdoch
>
> Martin
>
> > 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
>
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
More information about the R-devel
mailing list