[Rd] dput()

[Steven Dirkse]

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 <bbolker using gmail.com> 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 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?
> >>
> >> ______________________________________________
> >> R-devel using r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel using r-project.org 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]]