I have some complicated code in R that uses the neuralnet library for some computations.
Sorrily, I'm new to R and I'have less than a week to obtain some results using the existing code, which take quite a while in the processors I have to my disposal.
My idea is to implement the code via microsoft R open (MRO), which could accelerate the computations, but I haven't been able to install the neuralnet library via anaconda (I prefer anaconda because it's simple and allows to create environments easily). The installation goes with "Solving environment" forever.
Is there a way to install these libraries to be compatible with MRO on anaconda?? should i desist of using anaconda for this task?
Related
I am reading a book published in 2019 that uses a package (JWileymisc) that has been updated and some of the functions are deprecated, so I am spending too much time trying to update the examples. The authors use checkpoint package but I have not been able to make it work in my laptop (I don't have full rights and could not install R version 3.5.1).
I installed the older version of the package it is used in the book but I still get error message saying the functions could not be found. Is there a way around it without checkpoint and this old version of R? Or is it possible to call a function from an old version of a package? I am using Windows, by the way.
Thanks! :)
I recently installed R 4.0, after previously using relying R 3.6.3. To manage R repositories, I use Rstudio (currently 1.2.5042 on a Windows 10 machine). After upgrading to R 4.0, I opened a project from a few months ago, and realized that Rstudio is now, by default, using the newer version of R (and it's library folder). When running renv::restore(), renv attempts to re-install all libraries in the .lock file for the newer version of R, and I don't see any way to specify that I want to keep using R 3.6.3 and it's associated library.
Coming from a python background, I had assumed that renv would create a virtual environment that isolates both the interpreter and the libraries that the project uses (similar to how anaconda environments are created). However, after looking through the documentation and doing a few searches, I have found no reference to isolating a particular version of R. I have, however, found that Rstudio defaults to using the latest version of R, which is not necessarily the behaviour that I want.
I have tried using anaconda to manage an R environment. However, Anaconda relies on its own smaller repository of R packages, and many of the libraries I need are from researchers that house their code on GitHub.
Is there a way to create an R environment in which I can isolate both the R libraries and the version of R itself? Or, perhaps there is something I am missing about how environments with R/Rstudio are intended to be used?
You are correct that renv only manages the installed R packages, and not the R interpreter itself.
Depending on how you're using RStudio, you can still "fake" this by setting the RSTUDIO_WHICH_R environment variable. For example:
export RSTUDIO_WHICH_R=/path/to/R
rstudio
would tell RStudio to "bind" to the version of R specified by the RSTUDIO_WHICH_R environment variable.
For what it's worth, the ability to bind projects to a specific version of R is a feature of the professional editions of RStudio; however, it's not available in the open-source version. See here for more details.
I would like to be able to call R (2.15.3) from within R (3.0.2). In order to use a package (windows binary, not on cran) that is available in only the older version of R. Is this possible?
This is R. There is no if, only how
said Simon Blomberg.
You could call an older version of R using system() and the appropriate hacks in your OS. Which is something odd to do, and opens tons of possibilities for serious damage to your computer when you hit it in frustration.
Or you could download the source of the package and rebuild it in R 3.0. There's been some rather drastic internal changes in the way packages are built and used in R (the most obvious being the removal of support for packages without a namespace).
Hence :
if the package does not have a namespace: download the source (.tar.gz), read the manual "Writing R extensions" if you didn't before, and add a namespace file with the usual exports. As explained in Writing R extensions, this can be as simple as adding a single line
exportPattern("^[^\\.]")
if the package has a namespace, build from source on your machine and you should be good to go. This is simply done by using:
install.packages("path/to/package.tar.gz",type="source")
Note that if you want to install from source on a Windows machine, you'll need a compatible version of Rtools : http://cran.r-project.org/bin/windows/Rtools/
If you don't want to be bothered with it, mail the author/maintainer of the package and kindly ask if they'd like to rebuild it for you.
I'm trying to install the doMPI package in R.
Apparently there are no binaries available for the 3.x version?
Do i need to build it from source?
http://cran.r-project.org/web/packages/doMPI/
<>
The goal is to run parallel processing with caret on a windows machine.
CRAN doesn't build binaries of doMPI for Mac OS X or Windows because it depends on the Rmpi package, and it doesn't build binaries for Rmpi because it depends on MPI libraries which don't come by default on those platforms. Some people have suggested that I declare Rmpi to be a suggested package to work-around this issue, but in fact, doMPI really does depend on Rmpi, so it always seemed like an odd thing to do. The way I see it, if you're able to build Rmpi from source, you'll have no trouble building doMPI from source.
So yes, you have to build it from source, but the bigger problem is to build Rmpi from source, unless you're using a Linux distribution like Debian that distributes both Rmpi and doMPI as binary deb packages.
But if you just want to run caret in parallel on a Windows machine, the normal solution is to use the doParallel package using a PSOCK cluster. People have trouble with that as well, but at least installation of the packages is easy since there are binary packages available for doParallel on CRAN.
The new R 3.0.0 requires that all contributed packages are reinstalled. Two questions:
Does this also mean that software that calls R, e.g. rapache, need to be recompiled after R has been upgraded?
Are the new builds backward compatible? E.g. if an r-cran-xxx package has been compiled using r-base-dev 3.0.0, can this package be loaded in R 2.15? Or do we need to distribute separate binary packages for R 2.15 and R 3.0.0?
This is really a question for r-devel, or as you use our Debian / Ubuntu package terminology, r-sig-debian.
In short:
Question 1 is AFAICT a no. The R C API did not change. The design of Rapache heavily influenced our much smaller littler r, and r runs just fine on my Ubuntu box after installing R 3.0.0 from Michael's builds based on my packages. Even though littler (see r --version) was built against R 2.15.2.
Question 2 is a no, and that is no change. R always moves "forward in time", not backwards. Just how we need package rebuilds when NAMESPACES were added, and when the help format changed. So if you have N different R versions with M different ABIs for packages, you may need M trees and manage your libPaths. Nothing new here.