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