dput()

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

dput()

robin hankin-3
My interpretation of dput.Rd is that dput() gives an exact ASCII form
of the internal representation of an R object.  But:

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

Rui Barradas
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@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@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?
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

David Winsemius

On 2/28/20 11:42 PM, Rui Barradas wrote:
> Hello,
>
> FAQ 7.31
>
> See also this StackOverflow post:
>
> https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal 
>


That was going to be my initial response, but then I realized that the
question might be why the dput representation of the x variable didn't
display the detail of the decimal fraction out at the 16th or
seventeenth place. So here's some further results to chew on:


1 (rather than 0.99999999999999955591) is what would get if `dput` were
used to send it to a file:


  dput(x, file="temp.txt")

  x <- scan(file="temp.txt")
#Read 1 item

  x==1
#[1] TRUE

And if you wanted more precision with the value before it got rectified
by output/input  you could use the control parameter:


dput(x, control="digits17")
#0.99999999999999956


HTH;

David.

>
> 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@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@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?
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

Gabriel Becker-2
In reply to this post by Rui Barradas
Hi Robin,

In the future, questions like this belong on R-help, not R-devel as it is a
basic usage question not a discussion about development of the R language
itself or similar.

That said, ?dput states a number of times that exact deparsing is not
always possible and that dput is not appropriate for what I'm inferring you
may be trying to do with it.  I would not have expected this in particular
to be one of those cases, to be honest, but its within spec. dput is NOT
guaranteed to give back an identical object, in fact according to the docs
in some cases it should be expected not to. As for why dput is doing this ,
I'm not sure if its that some amount off formatting is going on inside
dput, or if its a finite precision issue as suggested by Rui. I think the
former is more consistent with the behavior you're seeing but I don't have
time to dig into the guts of dput right this second.

Either way, If you want exact recreation of the object you have you need to
either run the actual code you used to generate it (on the same data  in
the same environment, etc etc) or serialize it out via saveRDS (or just
save if you must) and then readRDS/load it back in.

I hope that helps.
~G


On Fri, Feb 28, 2020 at 11:43 PM Rui Barradas <[hidden email]> 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@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@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?
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

bbolker
In reply to this post by Rui Barradas

 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.

  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@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@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?
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

Duncan Murdoch-2
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@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@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?
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

robin hankin-3
 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 <[hidden email]> 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@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@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?
> >>>
> >>> ______________________________________________
> >>> [hidden email] mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

Steven Dirkse
In reply to this post by bbolker
Ben,

I'll edit and split your question just a little.
  1) "Is there a way to get an *exact* ASCII representation of a
double-precision value?"
  2) "Is there a way to get round-trip behavior, i.e. to make sure that the
value, when converted back to double, is identical() to the original"

The hexNumeric idea mentioned by Duncan is a positive answer to the first
question.  It's a little hard to grok at first, but it is fully precise and
represents exactly a 64-bit double.  And since it is exact it converts back
identically.

But there is another way to get round-trip behavior.  There is a set of
routines called dtoa that, when given an IEEE double, produce the shortest
sequence of base 10 digits that will map back to the double.  There may be
some rounding when producing these digits, but of all the digit sequences
that would map back to the input x, these routines produce the shortest
such.

A link to the original routines is here:

http://www.netlib.org/fp/dtoa.c

and some searching will turn up variants of this code in newer guises.

A good question to ask: for all finite doubles, what is the length of the
longest digit sequence required?  I believe 17 digits is the max digits
required.  It may be 18, but I doubt it.  I don't have an example at hand
and I spent some time looking when working with these routines.   Oh, BTW,
trailing or leading zeros do not count toward the length of the digit
sequence.

-Steve

On Sat, Feb 29, 2020 at 4:21 AM Ben Bolker <[hidden email]> 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.
>
>   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@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@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?
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


--
Steven Dirkse, Ph.D.
GAMS Development Corp.
office: 202.342.0180

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

Martin Maechler
In reply to this post by robin hankin-3
>>>>> 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
    > <[hidden email]> 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@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@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?
    >> >>>
    >> >>> ______________________________________________ >>>
    >> [hidden email] mailing list >>>
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> >>>
    >> >>
    >> >> ______________________________________________ >>
    >> [hidden email] mailing list >>
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> >
    >> > ______________________________________________ >
    >> [hidden email] mailing list >
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> >
    >>
    >> ______________________________________________
    >> [hidden email] mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel

    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

Duncan Murdoch-2
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
>      > <[hidden email]> 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@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@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?
>      >> >>>
>      >> >>> ______________________________________________ >>>
>      >> [hidden email] mailing list >>>
>      >> https://stat.ethz.ch/mailman/listinfo/r-devel
>      >> >>>
>      >> >>
>      >> >> ______________________________________________ >>
>      >> [hidden email] mailing list >>
>      >> https://stat.ethz.ch/mailman/listinfo/r-devel
>      >> >
>      >> > ______________________________________________ >
>      >> [hidden email] mailing list >
>      >> https://stat.ethz.ch/mailman/listinfo/r-devel
>      >> >
>      >>
>      >> ______________________________________________
>      >> [hidden email] mailing list
>      >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>      > ______________________________________________
>      > [hidden email] mailing list
>      > https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: dput()

Martin Maechler
>>>>> 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
    >> > <[hidden email]> 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@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@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?
    >> >> >>>

    >> > ______________________________________________
    >> > [hidden email] mailing list
    >> > https://stat.ethz.ch/mailman/listinfo/r-devel
    >>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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
    >>> > <[hidden email]> 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@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@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?

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel