Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.
If you have used Reot
before and tried to install it from CRAN recently, you may have noticed the following message:
Warning in install.packages : package ‘Reot’ is not available (for R version 3.0.2)
This is because the Reot
package was abandoned due to a name change suggested by Huug van den Dool, the author of the EOT algorithm and also the reviewer of our JSS paper introducing the package (about which I am very happy). Here's what he said:
I am in slight doubt whether Reot is a good acronym. It looks in that spelling like REOF which often means rotated EOF. In case there is EOF in R, and there must be, how would that be called? Not Reof!?
I totally agree with his reservation about the acronym and therefore decided to rename the package remote
which is short for R EMpirical Orthogonal TEleconections. So the name merely gained two letters. I thought it is quite clever as teleconnections imply forcing from some place not in the immediate vicinity of the observed phenomenon and therefore the term remote
seems to fit quite well (think television remote control).
Apart from the name change, remote
is really an enhanced version of Reot
. Not in the sense that computational performance was improved, but in the sense that it is now coded in an object oriented way. This means that R's native plot()
function will now work on objects returned by eot()
. Furthermore, the package has gained a predict()
function to use the identified linear models on new data not seen before by the model. This can be useful in many instances, e.g. to extend spatio-temporal data sets in time. In our paper (to which I will provide a link here as soon as it is published) we show one example using predict()
to downscale NDVI images for the region of Mt. Kilimanjaro. Here I quickly want to show how easy it is to use this new functionality (taken from the example 0f ?remote::predict()
). I would like to stress that this is solely to demonstrate the code, whether it is a valid application or not is another question.
library('remote') ### not very useful, but highlights the workflow data(pacificSST) data(australiaGPCP) ## train data using eot() train <- eot(x = pacificSST[[1:10]], y = australiaGPCP[[1:10]], n = 1) ## ## Calculating linear model ... ## Locating 1. EOT ... ## Location: 271.5 11.5 ## Cum. expl. variance (%): 79.82 ## predict using identified model pred <- predict(train, newdata = pacificSST[[11:20]], n = 1) ## compare results opar <- par(mfrow = c(1,2)) plot(australiaGPCP[[13]], main = "original", zlim = c(0, 10)) plot(pred[[3]], main = "predicted", zlim = c(0, 10))
Another enhancement is that remote
has gained classes EotMode
for a single mode and EotStack
for an object of multiple modes. The latter can be subset()
ed and names()
can be set and retrieved.
All in all, the new functionalities introduced in remote
should make the analyses much more pleasant and easier to code as the data handling functionalities should be more familiar, especially for people who have worked with the raster
package before. As we say in our paper, we are hopeful that there will be manifold applications where remote
may prove to be a useful tool.
R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.