Displaying 11 results from an estimated 11 matches for "digits17".
2016 May 05
1
Too many spaces in deparsed complex numbers with digits17 control option
If you set the "digits17" control option in deparse, you get a lot of
unnecessary space in the representation of complex numbers.
> deparse(0 + 0i)
[1] "0+0i"
> deparse(0 + 0i, control = "digits17")
[1] "0 + 0i"
As far as I can tell, the logic for this comes from t...
2020 Mar 02
2
dput()
...gt; 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 somethin...
2020 Feb 29
2
dput()
...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).
> >...
2020 Mar 02
0
dput()
...ntrol = "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&...
2020 Mar 02
0
dput()
...t;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...
2020 Feb 29
3
dput()
...f
'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 guarante...
2020 Feb 29
4
dput()
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 <-
2020 Feb 29
0
dput()
...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 th...
2020 Apr 24
0
R 4.0.0 is released
...now turns N into a list
also when val) has length one. This enables dimnames(r1)[[1]] <-
"R1" for a 1-row matrix r1, fixing PR#17719 reported by Serguei
Sokol.
* deparse(..), dump(..), and dput(x, control = "all") now include
control option "digits17" which typically ensures 1:1
invertibility. New option control = "exact" ensures numeric
exact invertibility via "hexDigits".
* When loading data sets via read.table(), data() now uses
LC_COLLATE=C to ensure locale-independent results for possible...
2020 Apr 24
0
R 4.0.0 is released
...now turns N into a list
also when val) has length one. This enables dimnames(r1)[[1]] <-
"R1" for a 1-row matrix r1, fixing PR#17719 reported by Serguei
Sokol.
* deparse(..), dump(..), and dput(x, control = "all") now include
control option "digits17" which typically ensures 1:1
invertibility. New option control = "exact" ensures numeric
exact invertibility via "hexDigits".
* When loading data sets via read.table(), data() now uses
LC_COLLATE=C to ensure locale-independent results for possible...
2020 Apr 24
0
R 4.0.0 is released
...now turns N into a list
also when val) has length one. This enables dimnames(r1)[[1]] <-
"R1" for a 1-row matrix r1, fixing PR#17719 reported by Serguei
Sokol.
* deparse(..), dump(..), and dput(x, control = "all") now include
control option "digits17" which typically ensures 1:1
invertibility. New option control = "exact" ensures numeric
exact invertibility via "hexDigits".
* When loading data sets via read.table(), data() now uses
LC_COLLATE=C to ensure locale-independent results for possible...