[Rd] dput()

[Martin Maechler]

>>>>> Martin Maechler 
>>>>>     on Mon, 2 Mar 2020 15:36:51 +0100 writes:

>>>>> Duncan Murdoch 
>>>>>     on Mon, 2 Mar 2020 04:43:53 -0500 writes:

    >> 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 :-).

    > Thank you -- you are right;
    > all "AllHex" is too non-orthodox and hence a pain for people to
    > get right, remember, etc.

    > In light of  Steven Dirkse's reply (and other much older e-mails
    > by others I remember only vaguely), it seems we still need to
    > find an example (with numbers) where it is not exact  ...
    > which makes  "exact" even more appropriate.

    > Martin

I've now committed these two proposals, using "exact" -- to
R-devel (i.e., for R 4.0.0).

(wanted in one svn commit, but accidentally needed 2: svn r77891 + ...2).

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?