From murdoch@dunc@n @end|ng |rom gm@||@com  Mon Mar  2 10:43:53 2020
From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch)
Date: Mon, 2 Mar 2020 04:43:53 -0500
Subject: [Rd] dput()
In-Reply-To: <24156.49861.922526.979505@stat.math.ethz.ch>
References: <CAHHjBM6zFE+UQrLeVT+gMD7R-jbHco+cygkAB+JR4P2cCik6bg@mail.gmail.com>
 <a0c1898c-2dac-cdd5-ff4b-5c91a30b065f@sapo.pt>
 <4d7acddc-485f-2de8-d802-e382b8f861be@gmail.com>
 <e3faa734-0db4-760d-ef1e-4f85e2382542@gmail.com>
 <CAHHjBM7uyFM+zZG=TFxmtahi1mKNnjsvbvhHnzv2xS2OpRVRgA@mail.gmail.com>
 <24156.49861.922526.979505@stat.math.ethz.ch>
Message-ID: <9ecdf3cd-c3af-9bee-dce1-ed0149d06462@gmail.com>

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 at 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 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
>      >> >
>      >> > ______________________________________________ >
>      >> 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
> 
>      > ______________________________________________
>      > R-devel at r-project.org mailing list
>      > https://stat.ethz.ch/mailman/listinfo/r-devel
>



[Rd] dput()
Duncan Murdoch