Re: [Rd] dput()
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.99955591) 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.99956 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? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.6.3 is released
The build system rolled up R-3.6.3.tar.gz (codename "Holding the Windsock") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.6.3.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 2b364f6eaef28e069ab8ed779ee5859d MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9 MD5 (R-latest.tar.gz) = 506c9576ba33e1262ad5b5624db9d96a MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60 MD5 (VERSION-INFO.dcf) = d97d382dc5583f9385461d8a4b0ff091 MD5 (R-3/R-3.6.3.tar.gz) = 506c9576ba33e1262ad5b5624db9d96a 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL 50381062bad9aeb4b0c8c4695cb6955c5ff70699fcc821a8e1b340229100278c NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.2 89302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES 2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a THANKS 20f8bfdfc6302bb2cf9b0fc5424c9a10ac0953096b6c32768ffd106a3fdd4589 VERSION-INFO.dcf 89302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f R-3/R-3.6.3.tar.gz This is the relevant part of the NEWS file CHANGES IN R 3.6.3: NEW FEATURES: * The included LAPACK has been updated to version 3.9.0 (for the included routines, just bug fixes). BUG FIXES: * Fixed a C level integer overflow in rhyper(); reported by Benjamin Tyner in PR#17694. * Uses of url(gzcon(.)) needing to extend buffer size have failed (with HTTP/2 servers), reported by G'abor Cs'ardi. * predict(loess(..), se=TRUE) now errors out (instead of seg.faulting etc) for large sample sizes, thanks to a report and patch by Benjamin Tyner in PR#17121. * tools:assertCondition(., "error") and hence assertError() no longer return errors twice (invisibly). * update(form, new) in the case of a long new formula sometimes wrongly eliminated the intercept from form, or (more rarely) added a garbage term (or seg.faulted !); the fix happened by simplifying the C-level logic of terms.formula(). Reported by Mathias Amb"uhl in PR#16326. * The error message from stopifnot(.., ) again contains the full "stopifnot(...)" call: Its attempted suppression did not work consistently. * On Windows, download.file(., , "wininet", headers=character()) would fail; reported with patch proposal by Kevin Ushey in PR#17710. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput()
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 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? > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput()
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?
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput()
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?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tcl problem with R-3.6.3?
Just built 3.6.3 from source and tcl doesn't work. Worked fine with the
same laptop in 3.6.2. Here's the exact error.
blurfle$ R --vanilla
R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.4 LTS
Matrix products: default
BLAS: /home/geyer/local/current/lib/R/lib/libRblas.so
LAPACK: /home/geyer/local/current/lib/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.6.3
> install.packages("aster")
--- Please select a CRAN mirror for use in this session ---
Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
[tcl] grab failed: window not viewable.
> q()
What's up with that?
--
Charles Geyer
Professor, School of Statistics
Resident Fellow, Minnesota Center for Philosophy of Science
University of Minnesota
char...@stat.umn.edu
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcl problem with R-3.6.3?
Here's a simpler example that should reproduce that error for you:
ans <- utils::select.list(c("hello", "world", "again"), graphics=TRUE)
Does it?
FYI, I installed R 3.6.3 from source on CentOS 7 a few hours ago, and
for me the above works just fine.
For your immediate needs of selecting a CRAN mirror, you can set:
options(menu.graphics = FALSE)
as a workaround to skip Tcl-based menus.
/Henrik
On Sat, Feb 29, 2020 at 10:01 AM Charles Geyer wrote:
>
> Just built 3.6.3 from source and tcl doesn't work. Worked fine with the
> same laptop in 3.6.2. Here's the exact error.
>
> blurfle$ R --vanilla
>
> R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> Copyright (C) 2020 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
> > sessionInfo()
> R version 3.6.3 (2020-02-29)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.4 LTS
>
> Matrix products: default
> BLAS: /home/geyer/local/current/lib/R/lib/libRblas.so
> LAPACK: /home/geyer/local/current/lib/R/lib/libRlapack.so
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.6.3
> > install.packages("aster")
> --- Please select a CRAN mirror for use in this session ---
> Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
> [tcl] grab failed: window not viewable.
> > q()
>
> What's up with that?
>
> --
> Charles Geyer
> Professor, School of Statistics
> Resident Fellow, Minnesota Center for Philosophy of Science
> University of Minnesota
> char...@stat.umn.edu
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcl problem with R-3.6.3?
I knew I could work around. But this shouldn't happen.
And yes. Same problem with your example.
blurfle$ R --vanilla
R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> ans <- utils::select.list(c("hello", "world", "again"), graphics=TRUE)
Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
[tcl] grab failed: window not viewable.
> q()
I didn't bother with sessionInfo() this time. I presume it would be the
same as before.
AFAIK this is a fully up to date Ubuntu 18.04 box.
On Sat, Feb 29, 2020 at 12:13 PM Henrik Bengtsson <
henrik.bengts...@gmail.com> wrote:
> Here's a simpler example that should reproduce that error for you:
>
> ans <- utils::select.list(c("hello", "world", "again"), graphics=TRUE)
>
> Does it?
>
> FYI, I installed R 3.6.3 from source on CentOS 7 a few hours ago, and
> for me the above works just fine.
>
> For your immediate needs of selecting a CRAN mirror, you can set:
>
> options(menu.graphics = FALSE)
>
> as a workaround to skip Tcl-based menus.
>
> /Henrik
>
> On Sat, Feb 29, 2020 at 10:01 AM Charles Geyer
> wrote:
> >
> > Just built 3.6.3 from source and tcl doesn't work. Worked fine with the
> > same laptop in 3.6.2. Here's the exact error.
> >
> > blurfle$ R --vanilla
> >
> > R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> > Copyright (C) 2020 The R Foundation for Statistical Computing
> > Platform: x86_64-pc-linux-gnu (64-bit)
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> > Natural language support but running in an English locale
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> > > sessionInfo()
> > R version 3.6.3 (2020-02-29)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 18.04.4 LTS
> >
> > Matrix products: default
> > BLAS: /home/geyer/local/current/lib/R/lib/libRblas.so
> > LAPACK: /home/geyer/local/current/lib/R/lib/libRlapack.so
> >
> > locale:
> > [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> > [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> > [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> > [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
> > [9] LC_ADDRESS=C LC_TELEPHONE=C
> > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats graphics grDevices utils datasets methods base
> >
> > loaded via a namespace (and not attached):
> > [1] compiler_3.6.3
> > > install.packages("aster")
> > --- Please select a CRAN mirror for use in this session ---
> > Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
> > [tcl] grab failed: window not viewable.
> > > q()
> >
> > What's up with that?
> >
> > --
> > Charles Geyer
> > Professor, School of Statistics
> > Resident Fellow, Minnesota Center for Philosophy of Science
> > University of Minnesota
> > char...@stat.umn.edu
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Charles Geyer
Professor, School of Statistics
Resident Fellow, Minnesota Center for Philosophy of Science
University of Minnesota
char...@stat.umn.edu
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcl problem with R-3.6.3?
> Charles Geyer
> on Sat, 29 Feb 2020 12:19:08 -0600 writes:
> I knew I could work around. But this shouldn't happen.
I assume capabilities()does show a FALSE for "tcltk" ?
In such cases, sessionInfo() may be extended:
> sfsmisc :: sessionInfoX() # returns even more; has a "nice" print() method
Extended sessionInfo():
---
Capabilities:
jpeg pngtiff tcltk X11aqua
X X X X X -
http/ftp sockets libxmlfifo cledit iconv
X X X X - X
NLS profmem cairo ICU long.double libcurl
X - X X X X
Sys.info:
nodenamev-lynne
usermaechler
LAPACK version: 3.9.0
External software (versions):
zlib1.2.11
bzlib 1.0.6, 6-Sept-2010
xz 5.2.4
PCRE8.43 2019-02-23
ICU 63.2
TRE TRE 0.8.0 R_fixes (BSD)
iconv glibc 2.29
readline8.0
BLAS/u/maechler/R/D/r-patched/F30-64-inst/lib/libRblas.so
PCRE (regex) config.: ("UTF-8" = TRUE, "Unicode properties" = TRUE, JIT = TRUE,
stack = TRUE)
R executable linked against libR.* ['is R shared']: FALSE
R_LIBS:
libPath [.libPaths()] contents in addition to R_LIBS and .Library:
[1] "/usr/local64.sfs/app/R/Bioconductor/library_3.10_F30"
[2] "/usr/local64.sfs/app/R/R_local/library_F30-3.6"
[3] "/u/maechler/R/x86_64-pc-linux-gnu-library/3.6"
Main R env. variables (for more, inspect the 'xR.env' component):
[,1]
R_ENVIRON "/u/maechler/R/Renviron64"
R_PROFILE "/u/maechler/R/Rprofile"
R_CHECK_ENVIRON "/u/maechler/.R/check.Renviron"
standard sessionInfo():
R version 3.6.3 Patched (2020-02-29 r77878)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Fedora 30 (Thirty)
Matrix products: default
BLAS: /u/maechler/R/D/r-patched/F30-64-inst/lib/libRblas.so
LAPACK: /u/maechler/R/D/r-patched/F30-64-inst/lib/libRlapack.so
locale:
[1] LC_CTYPE=de_CH.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=de_CH.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=de_CH.UTF-8
[7] LC_PAPER=de_CH.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=de_CH.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] graphics grDevices datasets stats utils methods base
other attached packages:
[1] fortunes_1.5-4 sfsmisc_1.1-5
loaded via a namespace (and not attached):
[1] compiler_3.6.3 tools_3.6.3tcltk_3.6.3
>
I'm not seeing any problems on my Linux platforms (all Fedora 30).
Martin
> And yes. Same problem with your example.
> blurfle$ R --vanilla
> R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> Copyright (C) 2020 The R Foundation for Statistical
> Computing Platform: x86_64-pc-linux-gnu (64-bit)
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain
> conditions. Type 'license()' or 'licence()' for
> distribution details.
> Natural language support but running in an English
> locale
> R is a collaborative project with many contributors. Type
> 'contributors()' for more information and 'citation()' on
> how to cite R or R packages in publications.
> Type 'demo()' for some demos, 'help()' for on-line help,
> or 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>> ans <- utils::select.list(c("hello", "world", "again"),
>> graphics=TRUE)
> Error in structure(.External(.C_dotTclObjv, objv), class =
> "tclObj") : [tcl] grab failed: window not viewable.
>> q()
> I didn't bother with sessionInfo() this time. I presume
> it would be the same as before.
> AFAIK this is a fully up to date Ubuntu 18.04 box.
> On Sat, Feb 29, 2020 at 12:13 PM Henrik Bengtsson <
> henrik.bengts...@gmail.com> wrote:
>> Here's a simpler example that should reproduce that error
>> for you:
>>
>> ans <- utils::select.list(c("hello", "world", "again"),
>> graphics=TRUE)
>>
>> Does it?
>>
>> FYI, I installed R 3.6.3 from source on CentOS 7 a few
>> hours ago, and for me the above works just fine.
>>
>> For your immediate needs of selecting a CRAN mirror, you
>> can set:
>>
>> options(menu.graphics = FALSE)
>>
>> as a workaround to skip Tcl-based menus.
>>
>> /Henrik
>>
>> On Sat, Feb 29, 2020 at 10:01 AM Charles Geyer
>> wrote:
>> >
>> > Just built 3.6.3 from source
Re: [Rd] R 3.6.3 is released
Or use the Roaster:https://github.com/dmedri/roaster/(feedback is welcome) Messaggio originale Da: Peter Dalgaard via R-devel Data: 29/02/20 10:19 (GMT+01:00) A: r-annou...@r-project.org Cc: r-devel Oggetto: [Rd] R 3.6.3 is released The build system rolled up R-3.6.3.tar.gz (codename "Holding the Windsock") this morning.The list below details the changes in this release.You can get the source code fromhttp://cran.r-project.org/src/base/R-3/R-3.6.3.tar.gzor wait for it to be mirrored at a CRAN site nearer to you.Binaries for various platforms will appear in due course.For the R Core Team,Peter DalgaardThese are the checksums (md5 and SHA-256) for the freshly created files, in case you wishto check that they are uncorrupted:MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4MD5 (COPYING) = eb723b61539feef013de476e68b5c50aMD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7bMD5 (NEWS) = 2b364f6eaef28e069ab8ed779ee5859dMD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9MD5 (R-latest.tar.gz) = 506c9576ba33e1262ad5b5624db9d96aMD5 (README) = f468f281c919665e276a1b691decbbe6MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60MD5 (VERSION-INFO.dcf) = d97d382dc5583f9385461d8a4b0ff091MD5 (R-3/R-3.6.3.tar.gz) = 506c9576ba33e1262ad5b5624db9d96a2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORSe6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d FAQf87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL50381062bad9aeb4b0c8c4695cb6955c5ff70699fcc821a8e1b340229100278c NEWS4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.012b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.289302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f R-latest.tar.gz2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a THANKS20f8bfdfc6302bb2cf9b0fc5424c9a10ac0953096b6c32768ffd106a3fdd4589 VERSION-INFO.dcf89302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f R-3/R-3.6.3.tar.gzThis is the relevant part of the NEWS fileCHANGES IN R 3.6.3: NEW FEATURES: * The included LAPACK has been updated to version 3.9.0 (for the included routines, just bug fixes). BUG FIXES: * Fixed a C level integer overflow in rhyper(); reported by Benjamin Tyner in PR#17694. * Uses of url(gzcon(.)) needing to extend buffer size have failed (with HTTP/2 servers), reported by G'abor Cs'ardi. * predict(loess(..), se=TRUE) now errors out (instead of seg.faulting etc) for large sample sizes, thanks to a report and patch by Benjamin Tyner in PR#17121. * tools:assertCondition(., "error") and hence assertError() no longer return errors twice (invisibly). * update(form, new) in the case of a long new formula sometimes wrongly eliminated the intercept from form, or (more rarely) added a garbage term (or seg.faulted !); the fix happened by simplifying the C-level logic of terms.formula(). Reported by Mathias Amb"uhl in PR#16326. * The error message from stopifnot(.., ) again contains the full "stopifnot(...)" call: Its attempted suppression did not work consistently. * On Windows, download.file(., , "wininet", headers=character()) would fail; reported with patch proposal by Kevin Ushey in PR#17710.-- Peter Dalgaard, Professor,Center for Statistics, Copenhagen Business SchoolSolbjerg Plads 3, 2000 Frederiksberg, DenmarkPhone: (+45)38153501Office: A 4.23Email: pd@cbs.dk Priv: PDalgd@gmail.com__r-de...@r-project.org mailing listhttps://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput()
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 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?
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcl problem with R-3.6.3?
Charles, Did you try a build of the provided alpha, beta and rc releases made available to allow you to ensure that the released version would build and perform as expected? FWIW the new 3.6.3 made ~ 12 hours ago are already available for Debian, built for the Ubuntu backports at CRAN (thanks to Michael) and also in the base Rocker container behaves as expected (and as the one RC build did): edd@rob:~$ docker run --rm -ti rocker/r-base R version 3.6.3 (2020-02-29) -- "Holding the Windsock" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > capabilities() jpeg pngtiff tcltk X11aqua TRUETRUETRUETRUE FALSE FALSE http/ftp sockets libxmlfifo cledit iconv TRUETRUETRUETRUETRUETRUE NLS profmem cairo ICU long.double libcurl TRUETRUETRUETRUETRUETRUE > And (to echo Martin Maechler) tcltk comes up as TRUE as it should. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcl problem with R-3.6.3?
No. I didn't do any of that and am now at a hockey game. But since I can't reproduce the problem after an Ubuntu online update and reboot, I assume the issue is moot. But I will check these things in an hour or so. On Sat, Feb 29, 2020, 3:24 PM Dirk Eddelbuettel wrote: > > Charles, > > Did you try a build of the provided alpha, beta and rc releases made > available to allow you to ensure that the released version would build and > perform as expected? > > FWIW the new 3.6.3 made ~ 12 hours ago are already available for Debian, > built for the Ubuntu backports at CRAN (thanks to Michael) and also in the > base Rocker container behaves as expected (and as the one RC build did): > > edd@rob:~$ docker run --rm -ti rocker/r-base > > R version 3.6.3 (2020-02-29) -- "Holding the Windsock" > Copyright (C) 2020 The R Foundation for Statistical Computing > Platform: x86_64-pc-linux-gnu (64-bit) > > R is free software and comes with ABSOLUTELY NO WARRANTY. > You are welcome to redistribute it under certain conditions. > Type 'license()' or 'licence()' for distribution details. > > Natural language support but running in an English locale > > R is a collaborative project with many contributors. > Type 'contributors()' for more information and > 'citation()' on how to cite R or R packages in publications. > > Type 'demo()' for some demos, 'help()' for on-line help, or > 'help.start()' for an HTML browser interface to help. > Type 'q()' to quit R. > > > capabilities() >jpeg pngtiff tcltk X11aqua >TRUETRUETRUETRUE FALSE FALSE >http/ftp sockets libxmlfifo cledit iconv >TRUETRUETRUETRUETRUETRUE > NLS profmem cairo ICU long.double libcurl >TRUETRUETRUETRUETRUETRUE > > > > > And (to echo Martin Maechler) tcltk comes up as TRUE as it should. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dput()
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 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?
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@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]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcl problem with R-3.6.3?
I realized I don't have to do those checks. It was not working again (same error) message when I got home, but after a reboot it worked fine. Of course it has tcl/tk because when it works, it brings up a gui chooser thingy that allows me to choose a CRAN mirror. On Sat, Feb 29, 2020 at 3:33 PM Charles Geyer wrote: > No. I didn't do any of that and am now at a hockey game. But since I > can't reproduce the problem after an Ubuntu online update and reboot, I > assume the issue is moot. But I will check these things in an hour or so. > > On Sat, Feb 29, 2020, 3:24 PM Dirk Eddelbuettel wrote: > >> >> Charles, >> >> Did you try a build of the provided alpha, beta and rc releases made >> available to allow you to ensure that the released version would build and >> perform as expected? >> >> FWIW the new 3.6.3 made ~ 12 hours ago are already available for Debian, >> built for the Ubuntu backports at CRAN (thanks to Michael) and also in the >> base Rocker container behaves as expected (and as the one RC build did): >> >> edd@rob:~$ docker run --rm -ti rocker/r-base >> >> R version 3.6.3 (2020-02-29) -- "Holding the Windsock" >> Copyright (C) 2020 The R Foundation for Statistical Computing >> Platform: x86_64-pc-linux-gnu (64-bit) >> >> R is free software and comes with ABSOLUTELY NO WARRANTY. >> You are welcome to redistribute it under certain conditions. >> Type 'license()' or 'licence()' for distribution details. >> >> Natural language support but running in an English locale >> >> R is a collaborative project with many contributors. >> Type 'contributors()' for more information and >> 'citation()' on how to cite R or R packages in publications. >> >> Type 'demo()' for some demos, 'help()' for on-line help, or >> 'help.start()' for an HTML browser interface to help. >> Type 'q()' to quit R. >> >> > capabilities() >>jpeg pngtiff tcltk X11aqua >>TRUETRUETRUETRUE FALSE FALSE >>http/ftp sockets libxmlfifo cledit iconv >>TRUETRUETRUETRUETRUETRUE >> NLS profmem cairo ICU long.double libcurl >>TRUETRUETRUETRUETRUETRUE >> > >> >> >> And (to echo Martin Maechler) tcltk comes up as TRUE as it should. >> >> Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> > -- Charles Geyer Professor, School of Statistics Resident Fellow, Minnesota Center for Philosophy of Science University of Minnesota char...@stat.umn.edu [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
