How can I make philentropy::distance(...) not display any text to the console? For example,
distance(rbind((1:3),(4:6)), method="avg")
displays "Metric: 'avg'; comparing: 2 vectors. avg 6" to the console. How do I make it not display anything?
For example, the sink() function only hides "avg 6":
sink(tempfile(), append=FALSE, split=FALSE)
distance(rbind((1:3),(4:6)), method="avg")
sink()
The invisible() function also does not work for me:
invisible(distance(rbind((1:3),(4:6)), method="avg"))
Here is some version information:
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 3
minor 5.3
year 2019
month 03
day 11
svn rev 76217
language R
version.string R version 3.5.3 (2019-03-11)
Related
I observed different behaviors of the pseudo RNG depending on the version of R (see code below).
Can someone explain this difference in behavior to me?
Best Regards,
> version; set.seed(1); rnorm(3); sample(1:100, 10);
_
platform x86_64-conda_cos6-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 3
minor 5.1
year 2018
month 07
day 02
svn rev 74947
language R
version.string R version 3.5.1 (2018-07-02)
nickname Feather Spray
[1] -0.6264538 0.1836433 -0.8356286
[1] 95 66 62 6 20 17 65 36 71 46
> version; set.seed(1); rnorm(3); sample(1:100, 10);
_
platform x86_64-apple-darwin13.4.0
arch x86_64
os darwin13.4.0
system x86_64, darwin13.4.0
status
major 3
minor 6.0
year 2019
month 04
day 26
svn rev 76424
language R
version.string R version 3.6.0 (2019-04-26)
nickname Planting of a Tree
[1] -0.6264538 0.1836433 -0.8356286
[1] 87 43 14 82 59 51 85 21 54 74
sample was changed in version 3.6.0. From https://stat.ethz.ch/pipermail/r-announce/2019/000641.html
The default method for generating from a discrete uniform
distribution (used in sample(), for instance) has been changed.
This addresses the fact, pointed out by Ottoboni and Stark, that
the previous method made sample() noticeably non-uniform on large
populations. See PR#17494 for a discussion. The previous method
can be requested using RNGkind() or RNGversion() if necessary for
reproduction of old results. Thanks to Duncan Murdoch for
contributing the patch and Gabe Becker for further assistance.
The output of RNGkind() has been changed to also return the
'kind' used by sample().
PR#17494 is shown here https://bugs.r-project.org/show_bug.cgi?id=17494.
3.6 introduced some changes. You can read about them here:
https://stat.ethz.ch/pipermail/r-announce/2019/000641.html
If necessary you can get the same behavior by calling some functions to get results to match previous versions. Look up ?RNGkind or ?RNGversion for more details.
The relevant section from the news file:
The previous method
can be requested using RNGkind() or RNGversion() if necessary for
reproduction of old results.
I recently updated to the most recent versions of R and R studio and suddenly chart.TimeSeries from the PerformanceAnalytics package is not working inside a loop.
For example if I highlight the code below in Rstudio and run it , it executes without errors (which you can confirm by checking the value of i = 3 after running) but no plots are produced
library(PerformanceAnalytics)
library(xts)
ts1 <- xts(1:12, order.by = as.Date("2018-05-01") + (-11:0))
i <- 0
for (i in 1:3) chart.TimeSeries(ts1)
However if I replace
for (i in 1:3) chart.TimeSeries(ts1)
with
chart.TimeSeries(ts1)
chart.TimeSeries(ts1)
chart.TimeSeries(ts1)
then 3 plots are produced as expected. Has anyone seen or noted this before or have an explanation for it ?
Update : The same happens if I use plot.xts (which is what chart.TimeSeries uses under the hood) in place of chart.TimeSeries.
> version
_
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 3
minor 5.0
year 2018
month 04
day 23
svn rev 74626
language R
version.string R version 3.5.0 (2018-04-23)
nickname Joy in Playing
R-Studio verison 1.1.423. PerformanceAnalytics version 1.5.2, xts version 0.10-2
I just ran your example and indeed, my result is the same as yours.
I changed
for (i in 1:3) chart.TimeSeries(ts1)
to
for (i in 1:3) print(PerformanceAnalytics::chart.TimeSeries(ts1))
and now all 3 charts are showing properly in my plots panel inside rstudio (I also use up-to-date versions)
Hope this answers your issue.
I have written a dispatch model in GAMS which optimizes by minimizing system costs. I want to loop runs of the model; Run the optimization, save the output, varying a single parameter(storageCap) -- increasing it by a small fraction each iteration, and running the model again. GDXRRW does not seem to be able to run on R v.3.3.1 -- "Bug In Your Hair".
Are you sure about gdxrrw not working on R 3.3.1? It surely works for me:
(1) Install gdxxrw using
install.packages("C:\\GAMS\\win64\\24.7\\gdxrrw\\win3264\\gdxrrw_1.0.0.zip",repos=NULL)
(2) Use a GAMS script like:
set i /i1*i10/;
parameter p(i);
p(i) = uniform(0,1);
display p;
execute_unload "p.gdx",p;
execute '"c:\program files\R\R-3.3.1\bin\Rscript.exe" p.R';
$onecho > p.R
R.version
library(gdxrrw)
p<-rgdx.param("p.gdx","p");
p
$offecho
You will see something like:
--- Job Untitled_56.gms Start 08/18/16 15:29:58 24.6.1 r55820 WEX-WEI x86 64bit/MS Windows
GAMS 24.6.1 Copyright (C) 1987-2016 GAMS Development. All rights reserved
Licensee: Erwin Kalvelagen G150803/0001CV-GEN
Amsterdam Optimization Modeling Group DC10455
--- Starting compilation
--- Untitled_56.gms(17) 3 Mb
--- Starting execution: elapsed 0:00:00.013
--- Untitled_56.gms(5) 4 Mb
--- GDX File C:\tmp\p.gdx
--- Untitled_56.gms(6) 4 Mb
_
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 3
minor 3.1
year 2016
month 06
day 21
svn rev 70800
language R
version.string R version 3.3.1 (2016-06-21)
nickname Bug in Your Hair
i p
1 i1 0.17174713
2 i2 0.84326671
3 i3 0.55037536
4 i4 0.30113790
5 i5 0.29221212
6 i6 0.22405287
7 i7 0.34983050
8 i8 0.85627035
9 i9 0.06711372
10 i10 0.50021067
*** Status: Normal completion
--- Job Untitled_56.gms Stop 08/18/16 15:29:59 elapsed 0:00:00.907
This question already has answers here:
Save a plot in an object
(4 answers)
Closed 7 years ago.
Two methods of storing plot objects in list or a name string are mentioned on this page Generating names iteratively in R for storing plots . But both do not seem to work on my system.
> plist = list()
> plist[[1]] = plot(1:30)
>
> plist
list()
>
> plist[[1]]
Error in plist[[1]] : subscript out of bounds
Second method:
> assign('pp', plot(1:25))
>
> pp
NULL
I am using:
> R.version
_
platform i486-pc-linux-gnu
arch i486
os linux-gnu
system i486, linux-gnu
status
major 3
minor 2.0
year 2015
month 04
day 16
svn rev 68180
language R
version.string R version 3.2.0 (2015-04-16)
nickname Full of Ingredients
Where is the problem?
Use recordPlot and replayPlot:
plot(BOD)
plt <- recordPlot()
plot(0)
replayPlot(plt)
Does the randomForest package ignore the nodesize parameter? When I predict the terminal nodes for a dataset and check the counts, I see values that are less than the nodesize. I would submit a fix for this myself but the underlying code was written in Fortran. If someone can confirm this behavior I will reach out to the package maintainer and hopefully start a fix.
> library(randomForest)
> set.seed(1)
> rf <- randomForest(mtcars[,-1], mtcars[,1], nodesize = 5)
> nodes <- attr(predict(rf, mtcars[,-1], nodes = TRUE), 'nodes')
# node counts of first tree
> table(nodes[,1])
# first row is the terminal node ID#, second row is the count
2 6 9 10 11 14 15 16 18 19
5 3 3 6 4 2 3 1 3 2
Adding system info:
Session info----------------------------------------------------------------
setting value
version R version 3.1.1 (2014-07-10)
system x86_64, mingw32
ui RStudio (0.98.1049)
language (EN)
collate English_United States.1252
tz America/Chicago
Packages--------------------------------------------------------------------
package * version date source
randomForest * 4.6.10 2014-07-17 CRAN (R 3.1.1)
Response from package maintainer:
That parameter behaves as the way that Leo Breiman intended. The bug
is in how the parameter was described. It’s the same as minsplit in
the rpart:::rpart.control() function:
the minimum number of observations that must exist in a node in order
for a split to be attempted.
I will change the description in the help file in the next version to
resolve this confusion.
Best, Andy