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