1. Program 1. Obese employees are given a monthly weight loss goal. If the goal is reached, the participant receives $100, otherwise the employer keeps the money. This is called the individual incentive.
2. Program 2. Obese employees are organized into groups of five, and each participant is given a montly weight loss goal. A sum of $500 dollars is evenly split among those participants who achieve their monthly weight loss goal. In the event that no participant achieves their montly goal, the employer keeps the incentive money. This is called the group incentive.

The researchers found that the group incentive was associated with greater average weight loss than the individual incentive. This result is especially interesting from a psychological perspective, but I was most drawn to the issue of cost. I found it odd that the authors focused on the fact that "both designs used the same up-front allocation of resources". Presumably, this is to argue that the second program was more effective at no additional up-front cost. For example, the authors write: "Similar to that in the individual-incentive group, the up-front allocation of incentives for meeting weight-loss goals was $100 per participant per month (totaling $21 000)." But, the authors later write that, over a 24 week period: "Mean earnings were $514.70 (SD, $522.60) in the group-incentive group and $128.60 (SD, $165.50) in the individual-incentive group (mean between-group difference, $386.10 [CI, $201.00 to $571.30]; P < 0.001)." Hence, it's clear that the second program is more expensive, as one might expect. It's also a little odd that the study consisted mostly of women (89%). The allocation of race/ethnicity was also somewhat imbalanced.

I like that the authors used confidence intervals throughout to summarize the differences in average weight loss (and incentive earnings) between groups. They also used p-values, but I think this was unnecessary. The authors used multiple imputation for missing weights at 24 and 36 weeks. I've always had trouble accepting multiple imputation of outcomes, because the imputation depends so heavily on the method and model used for imputation. In the appendix, the authors write that weight was imputed "adjusting for incentive group, age, sex, race, education, household income, baseline weight, importance of controlling weight, and confidence in controlling weight". No additional details are given about the model, although the software used to implement the method is listed (SAS PROC MI and MIANALYZE). Finally, I felt this senctence was incomplete: "To maintain the type I error rate while testing the 3 hypotheses of primary interest, we used a Bonferroni correction to define an α of 0.0167 as our threshold for statistical significance." The authors neglected that this approach attempts to control the familywise type I error rate. This is an important omission.

So that we know who to thank:

matt@deb6box$ svn log -r 62016 http://svn.r-project.org/R/trunk/src/include/R_ext/Connections.h
------------------------------------------------------------------------
r62016 | urbaneks | 2013-02-21 14:29:44 -0500 (Thu, 21 Feb 2013) | 1 line

add API to create custom connections
------------------------------------------------------------------------

Here is the header file itself, with credits. It looks like all of the Rconnection struct is made available. But, notice the warning!

matt@deb6box$ svn blame -r 62016 http://svn.r-project.org/R/trunk/src/include/R_ext/Connections.h
 11656     ripley /*
 11656     ripley  *  R : A Computer Language for Statistical Data Analysis
 62016   urbaneks  *  Copyright (C) 2000-2013   The R Core Team.
 11656     ripley  *
 11656     ripley  *  This program is free software; you can redistribute it and/or modify
 11656     ripley  *  it under the terms of the GNU General Public License as published by
 11656     ripley  *  the Free Software Foundation; either version 2 of the License, or
 11656     ripley  *  (at your option) any later version.
 11656     ripley  *
 11656     ripley  *  This program is distributed in the hope that it will be useful,
 11656     ripley  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 11656     ripley  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 11656     ripley  *  GNU General Public License for more details.
 11656     ripley  *
 11656     ripley  *  You should have received a copy of the GNU General Public License
 42308     ripley  *  along with this program; if not, a copy is available at
 42308     ripley  *  http://www.r-project.org/Licenses/
 11656     ripley  */
 11656     ripley 
 62016   urbaneks #ifndef R_EXT_CONNECTIONS_H_
 62016   urbaneks #define R_EXT_CONNECTIONS_H_
 62016   urbaneks 
 11668     ripley #include 
 11668     ripley 
 62016   urbaneks #ifndef NO_C_HEADERS
 62016   urbaneks # include  /* for size_t */
 62016   urbaneks # include  /* for va_list */
 42677   urbaneks #endif
 42677   urbaneks 
 62016   urbaneks /* IMPORTANT: we do not expect future connection APIs to be
 62016   urbaneks    backward-compatible so if you use this, you *must* check the version
 62016   urbaneks    and proceed only if it matches what you expect
 62016   urbaneks 
 62016   urbaneks    We explicitly reserve the right to change the connection
 62016   urbaneks    implementation without a compatibility layer.
 62016   urbaneks  */
 62016   urbaneks #define R_CONNECTIONS_VERSION 1
 62016   urbaneks 
 45984     ripley /* this allows the opaque pointer definition to be made available 
 44013     ripley    in Rinternals.h */
 16472       luke #ifndef HAVE_RCONNECTION_TYPEDEF
 16472       luke typedef struct Rconn  *Rconnection;
 16472       luke #endif
 16472       luke struct Rconn {
 11656     ripley     char* class;
 11656     ripley     char* description;
 44013     ripley     int enc; /* the encoding of 'description' */
 11656     ripley     char mode[5];
 23228     ripley     Rboolean text, isopen, incomplete, canread, canwrite, canseek, blocking, 
 23228     ripley 	isGzcon;
 18583     ripley     Rboolean (*open)(struct Rconn *);
 11656     ripley     void (*close)(struct Rconn *); /* routine closing after auto open */
 11656     ripley     void (*destroy)(struct Rconn *); /* when closing connection */
 11656     ripley     int (*vfprintf)(struct Rconn *, const char *, va_list);
 11656     ripley     int (*fgetc)(struct Rconn *);
 32497     ripley     int (*fgetc_internal)(struct Rconn *);
 31166     ripley     double (*seek)(struct Rconn *, double, int, int);
 13305     ripley     void (*truncate)(struct Rconn *);
 11656     ripley     int (*fflush)(struct Rconn *);
 11656     ripley     size_t (*read)(void *, size_t, size_t, struct Rconn *);
 11656     ripley     size_t (*write)(const void *, size_t, size_t, struct Rconn *);
 59167     ripley     int nPushBack, posPushBack; /* number of lines, position on top line */
 11656     ripley     char **PushBack;
 12256         pd     int save, save2;
 32492     ripley     char encname[101];
 32492     ripley     /* will be iconv_t, which is a pointer. NULL if not in use */
 32492     ripley     void *inconv, *outconv;
 32497     ripley     /* The idea here is that no MBCS char will ever not fit */
 32497     ripley     char iconvbuff[25], oconvbuff[50], *next, init_out[25];
 32497     ripley     short navail, inavail;
 32497     ripley     Rboolean EOF_signalled;
 44101     ripley     Rboolean UTF8out;
 41765     ripley     void *id;
 41765     ripley     void *ex_ptr;
 11656     ripley     void *private;
 61527     ripley     int status; /* for pipes etc */
 16472       luke };
 11656     ripley 
 62016   urbaneks #ifdef  __cplusplus
 62016   urbaneks extern "C" {
 62016   urbaneks #endif
 11656     ripley 
 62016   urbaneks SEXP   R_new_custom_connection(const char *description, const char *mode, const char *class_name, Rconnection *ptr);
 62016   urbaneks size_t R_ReadConnection(Rconnection con, void *buf, size_t n);
 62016   urbaneks size_t R_WriteConnection(Rconnection con, void *buf, size_t n);
 13366     ripley 
 62016   urbaneks #ifdef  __cplusplus
 62016   urbaneks }
 25961     ripley #endif
 25961     ripley 
 62016   urbaneks #endif

# convert degree, minute, second to decimal
dms2dec <- function(deg, min, sec) deg + (min + sec/60)/60
 
# convert degrees to radians
d2r <- function(d) d * pi / 180

# compute great circle distance (km) between two coordinates
# given in radians using the Haversine formula
hgcd <- function(lon1, lat1, lon2, lat2) {
    erth <- 6371 # average radius of earth (km)
    dlon <- (lon2 - lon1)
    dlat <- (lat2 - lat1)
    a <- sin(dlat/2)^2 + cos(lat1) * cos(lat2) * sin(dlon/2)^2
    c <- 2 * asin(min(1,sqrt(a)))
    erth * c
}

Location C (click to enlarge)

Location B (click to enlarge)

Location A (click to enlarge)

Until this new paper and implementation by Emerson et al., there were no widely available pairs plots that accommodated both numerical and categorical fields. ***Update 3/29/2013: ggpairs in the GGally package has been around since 2010***. A browse through the R Graph Gallery confirms this (as of 1/30/2013). See here too: a post on the Quick-R blog. I had been working on such a plot when I discovered the above article. Hence, I'm using this post to share my work, which I will probably abandon in favor of the above.

Any number of statistical graphics might be used instead of a scatterplot for numeric/numeric pairs; maybe a hexbin plot. A sieve plot or an association plot might be used as an alternative to the mosaicplot for factor/factor pairs. A beeswarm boxplot plot might be used in place of side-by-side boxplots for numeric/factor pairs.

Here was my provisional version of the generalized pairs plot, which I had called an 'association matrix plot':

pairsdf <- function(df, abbr = TRUE, abbr.len = 4) {
    par(mfrow = rep(length(df), 2))
    for (row in 1:length(df)) {
        xr <- df[[row]]
        if (is.character(xr) || is.logical(xr)) 
            xr <- as.factor(xr)
        if (is.factor(xr) && abbr) 
            levels(xr) <- abbreviate(levels(xr), 4)
        for (col in 1:length(df)) {
            xc <- df[[col]]
            if (is.character(xc) || is.logical(xc)) 
                xc <- as.factor(xc)
            if (inherits(xc, "factor") && abbr) 
                levels(xc) <- abbreviate(levels(xc), 4)
            cnm <- names(df)[col]
            rnm <- names(df)[row]
            if (col == row) {
                plot(c(0, 1), c(0, 1), type = "n", xaxt = "n", 
                  yaxt = "n", bty = "n", xlab = "", ylab = "", 
                  main = "")
                text(x = 0.5, y = 0.5, labels = cnm, adj = c(0.5, 
                  0.5), cex = 2)
            }
            else {
                iscf <- is.factor(xc)
                iscn <- is.numeric(xc)
                isrf <- is.factor(xr)
                isrn <- is.numeric(xr)
                if (isrf && iscf) {
                  mosaicplot(table(xc, xr), xlab = cnm, ylab = rnm, 
                    main = "", las = 2, color = TRUE, cex = 1.1)
                }
                else if (isrn && iscn) {
                  plot(xc, xr, xlab = cnm, ylab = rnm, main = "", 
                    las = 2, cex = 1.1)
                }
                else if (isrn && iscf) {
                  boxplot(xr ~ xc, xlab = cnm, ylab = rnm, main = "", 
                    las = 2, cex = 1.1)
                }
                else if (isrf && iscn) {
                  boxplot(xc ~ factor(xr, levels = rev(levels(xr))), 
                    xlab = cnm, ylab = rnm, main = "", las = 2, 
                    cex = 1.1, horizontal = TRUE)
                }
                else stop("urecognized variable type")
            }
        }
    }
}

Below are several association matrix plots generated by the above function (i.e., pairsdf) for data sets found in the MASS package. When there are many fields, I recommend using three to four square inches per plot.

It's easy to see that the coop data set describes a simple factorial experiment.


However, the Rabbit data clearly arose from a more complicated experiment.


The fields of the farms data set are all of the factor class.

In my own planning, I have defaulted to implementing power/precision analyses with Monte Carlo methods (i.e., simulation). I refer to the approach as "simulated power/precision analysis", but I concede that this may not be the best name. Indeed, there may be a more established name that is unknown to me. This approach initially requires more effort than using one of the many power/precision software packages. However, it's almost always more relevant to the proposed research. With practice, the simulation approach has become second nature, and I use it for complex and simple statistical strategies alike.

Below is an example of the simulation approach to compute the power of a test in a simple crossover design. Whenever a simulated power analysis is implemented, it's necessary to specify (1) how the data will arise, and (2) what statistical procedure will be applied. Note that there is no requirement that the statistical procedure should "match" the data generating mechanism. Rather, it's important that (1) is an accurate reflection of prior belief, and (2) is an accurate representation of the proposed statistical procedure. When (1) and (2) do match, as they do in this example, I am sometimes concerned that the resulting computations are optimistic.

In this example, $n$ patients will be recruited and given each of two treatments, where the order of treatments is randomized in a block fashion, so that the design is balanced in this regard. We assume that the data arise from a linear mixed effects model, where there is a random intercept for each patient, a treatment effect, an order effect, and a treatment-order interaction effect. The magnitude of each effect is specified, but may be zero. The statistical procedure is to fit a linear mixed effects model, compute a $(1-\alpha)\%$ confidence interval for the magnitude of the treatment effect, and finally to make an inference about its significance. We conclude that the treatment effect is (level $(1-\alpha)$) significant when the associated confidence interval fails to include the value zero:

# Simulate a crossover design with the formula:
# Response ~ 1 + Treatment + Order + Treatment:Order + (1 | Patient)
# Fit simulated data with linear mixed effects model. Make
# significance decision about treatment effect on the basis
# of 95% confidence interval (i.e., significant if 95% CI fails
# to include zero).

# n - number of patients in each order group
# sdW - within patient standard deviation
# sdB - between patient standard deviation
# beta - coefficient vector c(Intercept, Treatment, Order, Treatment:Order)
simulate <- function(n, sdW=4, sdB=1, beta=c(8, 4, 0, 0), alpha=0.05) {
    require("lme4")
    Patient   <- as.factor(rep(1:(2*n), rep(2, 2*n)))
    Treatment <- c(rep(c("Treatment1", "Treatment2"), n),
                   rep(c("Treatment2", "Treatment1"), n))
    Order     <- rep(c("First", "Second"), 2*n)
    Data      <- data.frame(Patient, Treatment, Order)
    CMat      <- model.matrix(~ Treatment * Order + Patient, data=Data)
    Response  <- CMat %*% c(beta, rnorm(2*n-1, 0, sdB)) + rnorm(4*n, 0, sdW)
    Data$Response <- Response
    Fit <- lmer(Response ~ (1 | Patient) + Treatment * Order, data=Data)
    Est <- fixef(Fit)[2]
    Ste <- sqrt(vcov(Fit)[2,2])
    prod(Est + c(-1,1) * qnorm(1-alpha/2) * Ste) > 0
}

# type I error for n=20 (result: 0.059)
#mean(replicate(1000, simulate(n=20, beta=c(8, 0, 0, 0))))

# type I error for n=50 (result: 0.057)
#mean(replicate(1000, simulate(n=50, beta=c(8, 0, 0, 0))))

# type I error for n=20 and order effect 2 (result: 0.062)
#mean(replicate(1000, simulate(n=20, beta=c(8, 0, 2, 0))))

# type I error for n=50 and order effect 2 (result: 0.05)
#mean(replicate(1000, simulate(n=50, beta=c(8, 0, 2, 0))))

# power for n=20 and treatment effect 4 (result: 0.869)
#mean(replicate(1000, simulate(n=20, beta=c(8, 4, 0, 0))))

# power for n=50 and treatment effect 4 (result: 0.997)
#mean(replicate(1000, simulate(n=50, beta=c(8, 4, 0, 0))))

Several scenarios are considered, including some checks on the type I error associated with the proposed procedure, and its power under three hypothetical data generating mechanisms. ***update 2012/02/23: commenter Paul rightly points out below that 1000 replications is insufficient for the implied precision of three decimal places!*** It's quite late as I'm writing this, and so I will end the discussion here. Indeed, I am trying to shorten my posts in an effort to make them more frequent! Please do comment if I've left out an important detail!

I am writing to urge you to help avoid the pending 8.2% budget cuts to the NIH, NSF, and federal statistical agencies. I feel that these cuts would be very harmful to the U.S. research infrastructure. These cuts are certain to cause talented young scientists to be driven from research by the disruption to their training and lack of jobs. Funding for research is not the cause of the nation's debt, and slashing research budgets will compromise our future. In closing, I respectfully request that you work with your colleagues to stop these pending budget cuts from taking effect in January.

Here is the original message:

I am writing to urge you to work with your fellow members of Congress and the president to ensure the pending across-the-board budget cuts do not take effect. The 8.2% budget cuts to the National Institutes of Health (NIH), the National Science Foundation (NSF), and the federal statistical agencies would be very harmful to the U.S. research and statistical data infrastructure.

The cuts to NSF and NIH would mean fewer grants at a time when a high proportion of highly rated proposals already go unfunded. This will affect all areas of research and prevent critical projects from being completed. Labs may be forced to close, resulting in layoffs of tens of thousands of researchers. It will take generations to recover the lost talent, as highly trained and dedicated young scientists and engineers will be driven from science by the disruption to their training and lack of jobs. The damage to our nation's health, security, and international competitiveness will be devastating.

The cuts to the statistical agencies could affect our decision making and ultimately cost the taxpayer more money. Data from the federal statistical agencies facilitate i) economic growth and development, ii) smart and efficient government, and iii) the saving of taxpayer money. As an example of the third point, extensive research, testing, and planning are under way now for the 2020 Decennial Census. The GAO has said that, unless major design changes are made, the 2020 Decennial Census could cost the American taxpayer $17 billion more than the 2010 Census. Reducing the U.S. Census Bureau budget could therefore undermine the critical 2020 Decennial Census cost-cutting work now being done.

Funding for research and statistical data is not the cause of the nation's debt, and slashing research budgets will compromise our future. In closing, I respectfully request that you work with your colleagues to stop the pending across-the-board budget cuts from taking effect in January. Federal investment is essential to fund the kind of critical research needed to develop new treatments for debilitating and costly illnesses, foster innovation in engineering, and address the increased demand for better nutrition. We must safeguard and sustain this essential public-private partnership that keeps our nation globally competitive and promotes economic growth and job creation.

• how to detect files with compressed data (and fail graciously)
• more details about the platform that generated the file (e.g., endianess, OS details)
• how to read files that were generated on a 32-bit 'Linux' platform

These are significant improvements. The details are documented in the 'sas7bdat' vignette, and online at the sas7bdat Github repository. The revised R package will be available on CRAN shortly, but is still EXPERIMENTAL.

The report - titled Taxes and the Economy: An Economic Analysis of the Top Tax Rates Since 1945^2,3 - addressed some of the evidence for the association between tax rates and economic growth, private savings, and investment. No statistically significant associations were found between tax rate (either the top marginal tax rate or the capital gains tax rate) and the degree of personal savings, personal investment, labor productivity, or per capita GDP growth. Hence, the report authors conclude that there is insufficient evidence to suggest that changes in tax rates affect these economic indicators.

But, while these authors did not find statistical significance, I found the associated graphics tell an interesting story:

Tax Rate vs. Personal Savings and Investment

Tax Rate vs. Per Capita GDP Growth

Alas, my name doesn't appear anywhere in the article or image caption. Also pictured (from left to right; those that I can name off the top of my head) are Nate Mercaldo, Dave Afshartous, Frank Harrell, and Sarah Fletcher.