See more details here.

update.packages(checkBuilt=TRUE)

This is because a bunch of packages have to be to rebuilt under R 3.0.0 in order to keep working.

So I did, but that was not enough for LyX to be able to compile my pdf's from knitr like it used to only a week ago. What I had to do besides was this:

remove.packages("tikzDevice")
install.packages("/Users/ghuiber/Downloads/tikzDevice_0.6.3.tar.gz", repos = NULL, type="source")

That is right. The package tikzDevice can no longer be installed directly from R-forge as a binary, as in

install.packages("tikzDevice", repos="http://R-Forge.R-project.org")

Also, the source files are only available as a .tar.gz archive. To install from it on a Windows machine, you must have Rtools installed first.

There is a workaround. First, install Oracle's manual download of 64-bit Java. As of this writing, its Windows 7 home will be in C:\Program Files\Java\jre7. You should add this to the %path% environment variable. In addition, the rJava package depends on jvm.dll, and R might be looking for it in the wrong spot. It won't hurt, then, to add this to your %path% as well: C:\Program Files\Java\jre7\bin\server. There's more on this, as usual, on StackOverflow.

As Oracle warns, your manually-installed 64-bit Java will not be automatically updated. That is a problem when security flaws hit Java, but I find being able to read Excel files into R so useful that I'm willing to just live with this risk, though I don't have a good idea how to best manage it. I'll just keep an eye on ArsTechnica for bug news. If anybody has a better way, I'm all ears.

a post on measures for logistic regression

// Reference: http://www.statisticalhorizons.com/r2logistic

// program definition
capture prog drop tjur2
program tjur2, rclass

if !inlist(e(cmd),"logit","logistic") {
   di as err "Tjur's R-squared only works after logit or logistic."
   exit 498 // Thank you, Nick Cox.
}
tempname yhat
predict `yhat' if e(sample)
local y `e(depvar)'
quietly ttest `yhat', by(`y')
local r2logistic r(mu_2)-r(mu_1)
di "Tjur's R-squared " _col(20) %4.3f `r2logistic'
return local r2logistic `r2logistic'

end

// use case
use "http://www.uam.es/personal_pdi/economicas/rsmanga/docs/mroz.dta", clear
logistic inlf kidslt6 age educ huswage city exper
tjur2

I'm not sure yet if it's worth saving this program as ado/personal/t/tjur2.ado for my future logistic regression diagnostic needs, but I haven't posted anything Stata-related in too long, so there you have it.

rm(list=ls(all=TRUE))

# define function to return duplicate packages and paths
tidyup <- function() {
   packs <- as.data.frame(installed.packages())
   paths <- levels(packs$LibPath)
   main <- subset(packs, LibPath==paths[2]) # base and recommended
   mine <- subset(packs, LibPath==paths[3]) # stuff I installed
   dups <- intersect(main$Package,mine$Package)
   return(list(paths,dups))
}   

# do the work:
cleanthis <- tidyup()
removethese <- cleanthis[[2]]          # here's the list of dups
fromhere <- cleanthis[[1]][3]          # I only want them on the main path
remove.packages(removethese, fromhere) # done

# check the result: 
# if length(tidyup()[[2]])=0, all is well. no dup packages left.
checkthis <- as.numeric(length(tidyup()[[2]]))

Why I wrote this:

A while back I chose to separate my package library over two file paths. One would be for base and recommended packages (1), the other for everything else (2). My notes on how I did that are here, and my reasons are here.

Today, I wanted to update my Zelig. I used the wizard -- source("http://r.iq.harvard.edu/zelig.installer.R") -- so I would get all the add-ons in one step. The wizard works under the assumptions that your library is all in one place. It installed a few packages that Zelig and its add-ons depend on on path (2), because it didn't find them there. They were present on path (1) though, so I ended up with duplicates. This is how I got rid of them.

But enough about Stata. What really blew me away was the textbook for the biostats section. Beautifully written, it takes its time to cover properly everything you need to know about hypothesis testing if you're an applied researcher. Most texts I've seen before hurried through this part like they couldn't wait to jump into regression diagnostics and the like. Maybe it's because I've only seen econometrics texts before.

Anyway, buy it if you're looking for an introductory text for applied stats of any kind, and biostats in particular. I'm not getting a penny for this plug, by the way, so feel free to try and find it for less elsewhere. And take the course when they offer it again. At the very least, it will make you an educated consumer of public health information.

packs <- as.data.frame(installed.packages())

You can see that this data frame has a column named Priority. The output of table(packs$Priority, exclude=NULL) shows that I have 14 base packages, 15 recommended ones, and 70 of the other kind -- user-contributed kit that I installed over time as I bumbled my way through learning and using R.

Looking at packs in the top left pane of Rstudio also shows that the rows are named after the packages. This means that you can collect the names of base and recommended packages easily:

> names(subset(packs, Priority=="recommended")$Package)
 [1] "boot"       "class"      "cluster"    "codetools"  "foreign"    "KernSmooth"
 [7] "lattice"    "MASS"       "Matrix"     "mgcv"       "nlme"       "nnet"      
[13] "rpart"      "spatial"    "survival" 

Having all the R packages in the same default library, which is /Library/Frameworks/R.framework/Versions/2.15/Resources/library as of this writing, comes with the disadvantage that when I upgrade to the next version of R I will have to re-install the 70 packages of the third kind.

It would be nice if I could set them aside in a different library, and any future version of R will know to look for them there and update them as needed.

There are two steps to this job: one is the actual moving of package folders; the other is to show R where to look for them.

First, I created a new folder called Rlibs. Then I moved the folders around with this Bash script, which I called movePacks.sh:

#!/bin/bash

# declare an array with the names of the base packages
basepacks=("base" "compiler" "datasets" "graphics" "grDevices" "grid" "methods" "parallel" "splines" "stats" "stats4" "tcltk" "tools" "utils")

# and another with the names of the recommended ones
recpacks=("boot" "class" "cluster" "codetools" "foreign" "KernSmooth" "lattice" "MASS" "Matrix" "mgcv" "nlme" "nnet" "rpart" "spatial" "survival")

# and now concatenate them
allpacks=("${basepacks[@]}" "${recpacks[@]}")

# where you're moving from
oldLib="/Library/Frameworks/R.framework/Versions/2.15/Resources/library"

# where you're moving to
newLib="/Users/ghuiber/Rlibs"

# first, move everything over
mv ${oldLib}/* ${newLib}

# then move the base and recommended packages back to their default location
for i in "${allpacks[@]}"
do
   mv ${newLib}/${i} ${oldLib}
done

Finally, to point R to the library folders, I created this .Renviron file as instructed by Christophe Lalanne in the comments to my earlier post on the topic:

R_PAPERSIZE=letter
R_LIBS=/Users/ghuiber/Rlibs
EDITOR=vim

The ideas for the R_PAPERSIZE and EDITOR environment variables came from here.

system.time(chol2inv(matrix(rnorm(2000^2),2000,2000)))

This took about 4 seconds to run, whether in RStudio or in command-line R 2.15.1. Mata, meanwhile, still takes about 30 seconds. I run Stata 12MP, all up to date. I'd be curious how SAS/IML does. I don't have it.

For some of us, it's a growing habit, as confessed in the last paragraph here. But scattered evidence so far suggests that a majority of MOOC consumers are dabblers -- a bit like president Obama, who may have done a bit of blow but didn't quite become a coke head. Below is a picture that supports this view.

The Learning From Data class at Caltech consists of 18 lectures, offered both over YouTube and iTunes U. I did both. If I knew I would be watching on a plane or in a hotel room, I downloaded them ahead of time to iTunes. Otherwise, I just watched them on YouTube. You can count the views for each video and of course they will change over time, but I think the general trend is right: a lot of people watch the first lecture, then peter out, with some peaks that may well be random, but my guess is that they are at specific topics visited by people who use this class as another reference.

My own experience may be typical. Though I took at least two online courses per year since the fall of 2008, I signed up for more. I have both signed up for courses I never took, and started courses I never finished. What can I say? It's a feast out there. I am grateful to the hosts, and I hope that they will get lots of good guests with the necessary youth and stamina. I mean, if I were an unemployed millennial, I'd occupy this.

R comes with a library folder where packages go -- both the base packages and the user-written ones you install over time. I'm not entirely sure what would be the best place for this folder so updates to all packages are as easy as possible.

It gets worse. On a Mac you have not one, but n+2 library folders. One is /Library/Frameworks/R.framework/Resources/library. Let's call it (1). The other n+1 are as many as there are historic versions of R on your computer, plus one. All are in /Library/Frameworks/R.framework/Versions/. In my case, they are as follows: n of them are in X/Resources/library, where X is 2.13, 2.14, and 2.15; one is in Current/Resources/library.

I know that the three library folders in X=2.15, Current and (1) are identical and updated simultaneously, though only the first shows up when I call .libPaths(). But when you update say, from 2.15 to 2.16, your historic versions remain frozen and the new (1) and Current folders reflect only 2.16. You have to install non-base packages all over again, by hand. Or do you? Is there a way to script an update of everything in the library folder at version t-1 when you update your R to version t? If anybody knows, please drop a comment. Thank you.