Can I use pairwise.wilcox.test() for post hoc test as my friedman.test() gat sifnificant?
I can't install pgirmass for the friedmanmc() function as its not compatible with my R version.
Does pairwise.wilcox.test() make sense for more than two samples?
Thank you for your help!
You haven't offered a specific example or an explanation of the the study design and hypotheses being tested, but the documentation does say that "corrections for multiple testing" are made, so you should be reasonably safe on statistical grounds. (There is some debate about the need for multiple comparisons tests.)
On the topic of the other package, you are misspelling its name and there is a current version available from CRAN for pkg:pgirmess. After reading the documentation of the two tests, I would probably trust the pairwise.wilcox.test more than the friedmanmc test because it is in a core R package, while the friedmanmc test appears to have undesireable behavior that gets suppressed in an awkward fashion, leading me to think it uses something of a statistical hack. I'm not encouraging you to do so but if your unstated R version is somewhat older, there may be suitable package versions, since I see versions going back to 2005 in the Archives.
Related
The R docs describe the ByteCompile field in the "DESCRIPTION file" section as:
The ‘ByteCompile’ logical field controls if the package code is to be byte-compiled on installation: the default is currently not to, so this may be useful for a package known to benefit particularly from byte-compilation (which can take quite a long time and increases the installed size of the package)
I infer the only detrimental side-effects to byte-compiling are (a) time-to-install and (b) installation size. I haven't found a package that takes too long during installation/byte-compiling, and the general consensus is that GBs are cheap (for storage).
Q: When should I choose to not byte-compile packages I write? (Does anybody have anecdotal or empirical limits beyond which they choose against it?)
Edit: As noted in the comments of an older question, the rationale that debugging is not possible with byte-compiled code has been debunked. Other related questions on SO have discussed how to do it (either manually with R CMD INSTALL --byte-compile ... or with install.packages(..., type="source", INSTALL_opts="--byte-compile")), but have not discussed the ramifications of or arguments against doing so.
I have yet to find a downside for byte-compiling, other than the ones you mention: slightly increased file size and installation time.
In the past, compiling certain code could cause slow-down but in recent versions of R (version >3.3.0), this doesn't seem to be a problem.
I am recompiling/upgrading my R install and I want to measure performance pre/post upgrade. Is there possibly a standard script to run to time some commonly used functions and libraries? I have already installed rbenchmark, but I am just not enough of an R user to know what type of code to write to properly benchmark the new installation.
I've seen people use R-benchmark-25 as on overall test of R.
When I compile BLAS's, I use something like what I post here to benchmark matrix operations from various packages.
I'm looking for some kind of references which explain the pro's en con's of using Rcpp when compared to using rdyncall.
Can someone who has used both explain the basic differences from an R package developers perspective who is interested in providing R wrappers to C++ code.
Thanks.
I think we mention rdyncall in the (brief) comparison to other approaches the intro vignette / JSS paper. It is a neat package, but aims for a much lower-level connection. As I understand it, it gives you C-level APIs with least amount of fuzz, as motivated by say, the rgl package. there is very good and detailed paper about rdyncall in a recent R Journal issue.
And unless I miss something, it does nothing for you on the C++ side. Whereas Rcpp makes use as .Call() to pass complete R objects back and forth, and manages to map a wide variety of R and C++ types automatically for you---with the possibility add your own mappers.
I found a package 'bivpois' for R which evaluates a model for two related poisson processes (for example, the number of goals by the home and the away team in a soccer game). However, this package seems to no longer be useable in newer versions of R.
Is there a reasonable way to modify the glm() function to do a similar process, or run this older package on my new version of R? I have found very little literature on these sorts of processes and have found very little in terms of easy implementation in other statistical packages like STATA.
Any suggestions would be much appreciated.
While CRAN does not host a current binary of bivpois, you can build the package from the archived source code (see http://cran.r-project.org/doc/manuals/R-exts.html#Checking-and-building-packages ). Building bivpois 0.50-3.1 from source (available at http://cran.r-project.org/src/contrib/Archive/bivpois/) works for me on R 2.15.0 Windows x64. The zipped Windows binary I built is available here: http://commondatastorage.googleapis.com/jthetzel-public/bivpois_0.50-3.1.zip .
You can feel free to refer to odds modelling and testing inefficiency of sports-bookmakersas I had modified the relevant functions inside bivpois package.
I'm looking for a an R package which can be used to train a Dirichlet prior from counts data. I'm asking for a colleague who's using R, and don't use it myself, so I'm not too sure how to look for packages. It's a bit hard to search for, because "R" is such a nonspecific search string. There doesn't seem to be anything on CRAN, but are there any other places to look?
I've only come across both R and the Dirichlet distribution in passing, so I hope I'm not too much off the mark.
This mailing list message seems to answer your question:
Scrolling through the results of
RSiteSearch("dirichlet") suggests some useful tools
in the VGAM package. The gtools package and
MCMC packages also have ddirichlet() functions
that you could use to construct a (negative log) likelihood
function and optimize with optim/nlmin/etc.
The deal, DPpackage and mix packages also may or may not provide what you need.
Then again, these are all still CRAN packages, so I'm not sure if you already found these and found them unsuitable.
As for searching for R, the R project site itself already provides a few links on its search page.