Why should you use git/GitHub?

Version control systems like git have long been used by programmers to sanely collaborate and organize software projects and they can serve the same purpose for quantitative researchers who spend much of their time coding. If you have never used version control systems, then the process can seem arcane and the benefits unclear. Once you start using a version control system, however, it becomes difficult to see how you ever got by before. What are some of the benefits of this approach?

First and probably foremost, git will allow you to collaborate sanely. Users make changes to code (“commits”) and then “push” them to a centrally shared repository (located at GitHub, for example). Other users can clone this repository and then easily “push their own changes as well as”pull” in other changes, allowing everyone to easily stay in-sync. Complex coding projects can also be “branched” and then later merged back into the main code base to avoid conflicts between users.

Second, by using version control systems, you effortlessly create your own research log. All changes to your code base are committed to the repository with a brief description of your changes. Collectively these commits serve as a research log of your work. You no longer have to remember when exactly you added that one variable to the model. The changes are right there in your history log.

Third, you can stop fearing change. Have you been in the situation where you know your code kind of works, but maybe its not the best? People often do one of two things in this situation. You might just leave it alone, because why mess with a piece of code that seems to work? Are you trying to anger the coding gods? Alternatively, you might decide to fix it, but fearful that you might make it worse, you duplicate the file (with a name like “analysis_just_trying_a_thing_v2.R”). Neither of these approaches is great. If you use version control, you can make radical changes to your code without fear. Did you mess it up? No worries, just revert back to the last “commit” and try again. To draw out an analogy from Hadley Wickham, the “free-climbing” approach to coding is dangerous and scary. Git is there to catch you when you fall.

Fourth, you can finally keep your project tidy. The tendency I note above to simply duplicate files with slightly different names (“paper-v2.1_06272017_FINAL_REALLY_THIS_TIME.docx”) is its own form of very inefficient version control. Over time, the directory containing your project becomes littered with files, and the ability to understand this chaos is locked deep somewhere in your own brain alone. If you practice this form of horizontal versioning, then help is on the way! Proper version control systems, like git, use “vertical” versioning. Because all of your changes are tracked on any given file, there is no need to duplicate a bewildering array of slightly different versions of the same file. Because you no longer need to fear change, you can keep your project tidy and compact. You only need one script to organize and clean your data. You only need one file to write the paper. Your project will suddenly become easier to navigate for yourself and everyone else.

Your First GitHub Repository

Have I piqued your interest? Lets talk about how to set up a git repository using RStudio and link it to an online repository on GitHub. The instructions here assume that you have some directory with R code in it that you want to turn into a repository on GitHub. You will also need to create an account on GitHub. I also will assume you are using RStudio to run R which provides a nice user interface for working with git.

Git itself is a command line interface. You can work with it from inside RStudio using a GUI interface but to get it set up properly, you will need to be able to work on the command line in the working directory of your project. The easiest way to use the command line in RStudio is to use the “Terminal” tab right next to the console tab in the lower left panel. You should see something like:

If you are on a Windows system, you will want a UNIX style command line. When you install git (as described below), you will gain access to a UNIX style terminal with an application called Git Bash. You can set git bash to be your default terminal in the RStudio preferences.

One thing to keep in mind is that GitHub has a single file size limit of 100 mb. If you have a single file in your directory that is larger than 100 mb, then GitHub will not allow you to push that file up to your GitHub repository. This issue most frequently arises with large datasets. Sometimes this can be fixed by compressing the file, since R can read directly from compressed files. Another solution is to host the large file somewhere else (e.g. DropBox).

library(usethis)
use_git_config(user.name = "Jane Doe", user.email = "jane@example.com")
git_vaccinate()

create_github_token()

gitcreds::gitcreds_set()

usethis::git_sitrep()

git init

git remote add origin https://github.com/AaronGullickson/example_project.git
git branch -M main
git push -u origin main

The basic git workflow

Now that you have your R project connected to GitHub, you can use the basic git workflow to keep your project synced between the two repositories. When you sit down to work on the project, you should do the following:

1. Pull changes from the main repository on GitHub to the local repository. This will ensure that your local repository has all of the latest changes made to the central repository (for example by a co-author).
2. Make changes to the project as desired. When you are satisfied with those changes, commit them to your local repository with a helpful message like “imputed missing values” or “corrected my horrible grammar.”
3. Committing only adds the changes to your local repository. If you want to make sure everyone has access to those changes, you then push the changes to the central repository on GitHub.

Lets go through a simple example of this workflow on my project. I want to change the default ggplot colors of the graph in my R Markdown document to something more … colorful. I am going to use the wonderful Wes Anderson R color palette instead. To do that I need to add the appropriate library and the following line to my ggplot command:

scale_fill_manual(values=wes_palette("Darjeeling1", 3, type = "discrete"))+

Once I make these changes, the git tab will show that my R Markdown file has been modified:

Hitting the commit button will bring up the commit dialog which will show me all of the pending changes. I can select any changes I want to commit and write a helpful commit message.

Once I commit these changes, I can then use the handy “Push” button to push these changes up to the GitHub repository. You can see for yourself how well this works by exploring this example GitHub repository.

In many cases you may repeat step (2) multiple times before pushing. When possible it makes sense to break up your commits into logical chunks in which you complete a certain task rather than “all the stuff I did today.” This will make it easier to understand your log history later. So you may actually do 3-4 smaller commits and then when you push, all of those commits will be pushed up to the GitHub repository at the same time.

You can do so much more!

This tutorial is intended to get you set up with the basic git workflow connecting a local R project to a GitHub repository. This provides powerful functionality but is really only the tip of the iceberg of what git can do for you. Git offers the ability to work in multiple branches and to revert changes. GitHub offers additional features for collaboration, most notably the wonderful pull request feature. But even the basic git workflow can help change the way that your organize your work and allows you to code with the confidence that you are no longer “free-climbing” your research. Happy gitting!

How did R know what to do with the factor variable?

Underneath the surface, every factor variable in R comes with a a matrix of contrasts. This contrast matrix defines how such a factor variable should be converted into a set of variables for a linear model. You can see this contrast matrix with the contrasts command:

contrasts(earnings$education)

##                  HS Diploma AA Degree Bachelors Degree Graduate Degree
## No HS Diploma             0         0                0               0
## HS Diploma                1         0                0               0
## AA Degree                 0         1                0               0
## Bachelors Degree          0         0                1               0
## Graduate Degree           0         0                0               1

The rows are the categories (or “levels” in R speak) of the factor variable and the columns are the variables that actually enter into the model. The matrix gives the numeric coding of these variables for each category. As you can see, the contrasts here just define a standard dummy/indicator variable coding. The no high school diploma category is my reference and has zero on all four variables. All of the other categories have a one for the relevant variable and a zero otherwise.

When you create a factor variable, R will default to this dummy coding which in R is often called a treatment contrast. But, treatment contrasts are not the only contrasts available and you can create your own contrast as I will show below.

To illustrate a change in contrast, I will change my regular factor variable to an ordered factor. The factor command has the option to make any factor ordered and thus recognize its underlying ordinal structure. I can do this very simply:

earnings$educ_ordered <- factor(earnings$education, ordered=TRUE)

An ordered factor behaves very similarly to a regular factor but has one major advantage. I can now use greater than and less than operators on my factor in a logical way. For example, lets say I wanted to look at the mean difference in wages between all those with only a high school diploma or less and those with more schooling. Rather than code a whole new variable for this binary comparison, I can just:

model_binary <- lm(wages~I(educ_ordered>"HS Diploma"), data=earnings)
knitr::kable(round(coef(model_binary), 2), col.names = "coefficients")

Being able to use these operators can be a real time saver if you have an ordinal variable with many categories because you can easily collapse categories for a variety of purposes.

However, ordered factors come with one very annoying “feature” in R. Lets say I want to estimate the same linear model as before but now using my ordered factor. Lets try it out:

model_ordinal1 <- lm(wages~educ_ordered, data=earnings)
knitr::kable(round(coef(model_ordinal1), 2), col.names="coefficients")

😮 WTF? What are all of these terms? They certainly are not what I was expecting. We can learn more by looking at the contrasts.

contrasts(earnings$educ_ordered)

##              .L         .Q            .C         ^4
## [1,] -0.6324555  0.5345225 -3.162278e-01  0.1195229
## [2,] -0.3162278 -0.2672612  6.324555e-01 -0.4780914
## [3,]  0.0000000 -0.5345225 -4.095972e-16  0.7171372
## [4,]  0.3162278 -0.2672612 -6.324555e-01 -0.4780914
## [5,]  0.6324555  0.5345225  3.162278e-01  0.1195229

We are definitely not using dummy coding here! The default behavior in R for ordered factors is to treat them as equidistant scores and then estimate an orthogonal polynomial function. So the letters L, Q, and C above refer to linear, quadratic, and cubic terms. This default behavior was inherited from S and I would argue that it is … not optimal. First, It is problematic to treat ordinal variables as equidistant scores without letting the researcher make that decision explicitly. Second, the parameter estimates from this approach are completely uninterpretable.

Luckily, it is not difficult to re-specify the contrasts for the education variable. R even provides some handy-dandy functions for common contrasts. In this case, we could re-code back to a standard dummy/indicator variable contrasts with contr.treatment, like so:

contrasts(earnings$educ_ordered) <- contr.treatment(5)
model_ordinal2 <- lm(wages~educ_ordered, data=earnings)
knitr::kable(round(coef(model_ordinal2), 2), col.names="coefficients")

Use the stairstep contrast, tell a friend

However, since we have to re-specify our contrasts, why not take the time to think about better options? The standard dummy variable coding for ordinal variables is often not very informative. For example, I can see that individuals with a graduate degree make $23.91 more per hour than those with no high school diploma. That is a large difference, but I would have expected a large number here given that we are contrasting the poles of the distribution. A far more interesting question is how much more do those with graduate degrees make than those with only a bachelor’s degree? In that case, we are comparing how much the predicted value of the dependent variable changes when you move to the next highest adjacent category.

We can do this for all adjacent pairs by applying a diff to the vector of mean wages:

diff(wage_means)

##       HS Diploma        AA Degree Bachelors Degree  Graduate Degree 
##         4.407462         3.242862         8.848246         7.410229

Every number gives us the increase in mean hourly wages when you move to that education level from the immediately preceding educational level. The biggest jump is between a Bachelor’s degree and an AA degree, while the smallest jump is between a high school diploma and an AA degree.

I can of course calculate these differences by hand from the results of my dummy variable coding. For example, by taking \(23.91-16.50\), I will be able to see that the increase in expected hourly wages from a Bachelor’s degree to a Graduate degree is 7.41. However, wouldn’t it be nice if there was a contrast coding that would do this for me? It turns out there is!

The contrast coding we want looks like a stairstep.

cont <- matrix(0, 5, 4)
cont[col(cont)<row(cont)] <- 1
rownames(cont) <- c("LHS","HS","AA","BA","Grad")
colnames(cont) <- c("HS vs LHS", "AA vs HS", "BA vs AA", "Grad vs BA")
cont

##      HS vs LHS AA vs HS BA vs AA Grad vs BA
## LHS          0        0        0          0
## HS           1        0        0          0
## AA           1        1        0          0
## BA           1        1        1          0
## Grad         1        1        1          1

In this coding, each category gets a one if it is at or higher than the critical cut point for that contrast. The idea is that every category gets the effect of making that “jump” if they are at that level or higher. The result looks like a stairstep descending to the left. For this reason, I often call this approach stairstep coding.

Lets try out this stairstep contrast on education:

contrasts(earnings$educ_ordered) <- cont
model_ordinal3 <- lm(wages~educ_ordered, data=earnings)
knitr::kable(round(coef(model_ordinal3), 2), col.names="coefficients") 

The contrasts behave exactly as expected. Each parameter estimate gives the mean difference between adjacent pairs of categories on the ordinal variable. We can get the mean differences between any non-adjacent pairs simply by adding up the values of all the intervening pairs. For example, to get the difference between an AA degree and a graduate degree I take the two values for BA vs. AA and Grad vs. AA and add them up for \(8.85+7.41=16.26\).

Finally, since setting up this contrast is a hassle, why not put all of it into a function like a coding ?

ordered_factor <- function(fact_var) {
  ord_fact <- factor(fact_var, ordered=TRUE)
  categories <- levels(fact_var)
  n_cat <- length(categories)
  cont <- matrix(0, n_cat, n_cat-1)
  cont[col(cont)<row(cont)] <- 1
  rownames(cont) <- categories
  colnames(cont) <- paste(categories[2:n_cat], categories[1:(n_cat-1)],
                          sep=" vs. ")
  contrasts(ord_fact) <- cont
  return(ord_fact)
}

This function take a factor variable as input and returns an ordered factor with stairstep contrasts defined as well as intuitive labels. Now you can just apply this function to any existing factor variables to convert them to ordered factors with stairstep contrasts. Here it is in action.

earnings$education <- ordered_factor(earnings$education)
contrasts(earnings$education)

##                  HS Diploma vs. No HS Diploma AA Degree vs. HS Diploma
## No HS Diploma                               0                        0
## HS Diploma                                  1                        0
## AA Degree                                   1                        1
## Bachelors Degree                            1                        1
## Graduate Degree                             1                        1
##                  Bachelors Degree vs. AA Degree
## No HS Diploma                                 0
## HS Diploma                                    0
## AA Degree                                     0
## Bachelors Degree                              1
## Graduate Degree                               1
##                  Graduate Degree vs. Bachelors Degree
## No HS Diploma                                       0
## HS Diploma                                          0
## AA Degree                                           0
## Bachelors Degree                                    0
## Graduate Degree                                     1

model_final <- lm(wages~education, data=earnings)
knitr::kable(coef(model_final, 2), col.names="coefficients")

Why you shouldn’t report odds ratios anyway

I understand that my student just wants to do what their advisor asked, but personally I am not a big fan of reporting odds ratios rather than log odds ratios. Here is what I explained to the student in my response (along with the code to do it anyway):

Personally, let me just say that I prefer to see the log-odds ratios for logistic regression models for a couple reasons. First, the sign on the log-odds ratio directly indicates a positive or negative relationship which is the first thing your brain is scanning for when you look at a table of regression coefficients. The extra cognitive work of remembering <1 means negative for an odds ratio is not worth it. Second, when the log-odds ratios are small the effect is easy to interpret as the percentage change. So a log-odds ratio of 0.07 is a 1.0725 odds ratio, so about a 7.25% increase in the odds. The 0.07 gives you a pretty good approximation of that. This logic breaks down when you get values above 0.25 or so, but makes it easy to get a general sense of the strength from the log odds ratio. Third, the standard error from the model is for the log-odds ratio not the odds ratio and you can’t convert it in any meaningful way, so its odd to report it with an odds ratio.

Step 1: Prepare your files

How to properly organize your data and code files for the easy accessibility of others is beyond the scope of this post, but here I want to highlight two basic minimum requirements that should be met before you make files available to reviewers:

1. Anonymize. You are submitting these files under anonymous peer review. Therefore, you should ensure that nothing in the files can identify you. Remove all names or anything else that could identify you.
2. Provide a Guide. You need to provide some basic information that will allow readers to understand what is contained in your files. A simple README file will usually suffice. This README should explain what each of the scripts does, the order in which those scripts should be run to reproduce the analysis, and distinguish which data is from the original source and which has been constructed by the analyst. Ask yourself a simple question: Would other people be able to figure out how to replicate the analysis in these files without having me there to explain it to them? If the answer is no, then you need more documentation.

Step 2: Set up an OSF Project with View-only Links

The Open Science Foundation provides an excellent tool for organizing research projects and disseminating information about them. You can associate manuscripts, data, and code with projects, track changes to the project, and even include a wiki. You can also link your OSF project to manuscripts on SocArxIV. Here is an example of a project for one of my own recently published papers. If you don’t already have an account, you should create one.

You can create a view-only link for any OSF project. A view-only link will open up the project page, but with all name references removed. Here is an example of that same example project of mine but provided through a view-only link. Notice that contributors are listed as “Anonymous” and the person responsible for all changes to the project is listed as “user.” UPDATE: As noted by Phil Cohen on Twitter, this link provides “courtesy” anonymity, not secure anonymity. A sophisticated viewer can still access the named project page by removing the “?view_only” part of the html address.

To set up a view-only link for a project, follow these steps:

1. Go to the project Settings tab.
2. In the View-only Links section, click the green “+Add” button. This will bring up a dialog with more options. You must click the button to “Anonymize contributor list for this link”. If your project has multiple components, you can also decide which components to add here.
3. Now you should see a description of your View-only Link with the option to copy the full link. Here is what mine looks like:

To make this link available to reviewers, I include the link directly in a footnote on the first page of my manuscript with instructions that reviewers can find all code and data as well as supplementary analyses at that location.

But how do you get code and data into the project? You can just drag and drop your code and data files into the files section on your OSF project. However, if you use git (subliminal message: you should use git) for version control, there is a better way.

Step 3: Link OSF to your GitHub data

Github (or other git platforms like Gitlab) provides an excellent tool to disseminate data and code, include documentation, and to update that code and data with a proper log of all changes. Here is an example of a GitHub repository with code for the reproduction of an analysis.

Thankfully, OSF provides the ability to link to your GitHub repository. Just go to the “Add-ons” tab of your OSF project and enable the GitHub (or GitLab) settings. After authenticating with GitHub, you will then have the ability to select a repository to be associated with the project. Here is an example of what this looks like in my project:

Once you have selected a repository, that repository will show up in the files section of your OSF project. If you make any changes to that data and code, those changes will automatically be updated on OSF once you push them to your GitHub repository. You no longer have to worry about manually moving over new files if you make a change.

Importantly, you can link private repositories here as well. So if you want to keep your code and data private until publication, you can set your GitHub repo to private but still make it available to reviewers through OSF.

If you are git-averse, then its worth noting that you can also link to Dropbox and OneDrive if you want to keep your data and code there instead.

The Data

The data I am using come from a data extract of the General Social Survey (GSS). I am particularly interested in the variable PRAY in this dataset. Yes, the GSS capitalizes all of its variable names because REASONS. You can access the CSV data here.

gss <- read.csv("gss_relig.csv")
table(gss$PRAY)

## 
##     0     1     2     3     4     5     6     8     9 
## 28232  9065  9936  4099  2321  5469  2239    96   302

The default data came in numeric format. The online codebook for the GSS tells me that these numeric codes correspond to the following categories.

Ultimately, I want to turn these numeric codes into a proper factor variable. There are several issues to consider before proceeding:

1. There are multiple missing value codes to enter (0,8,9)
2. The numbering is the reverse of how I want the ordinal variable coded. I want higher values to indicate higher frequency of prayer.
3. Most importantly, the category of “Never” was not given as an explicit option until 2004, so I can’t compare data across time very well with that category. Therefore, I want to collapse the “Never” and “Lt once a week” category together.

My Old Approach

My old approach to handling this sort of re-code problem would have been to apply what I call the bracket and boolean approach. Here is what that code would look like:

gss$pray <- NA
gss$pray[gss$PRAY==5 | gss$PRAY==6] <- "lt once a week"
gss$pray[gss$PRAY==4] <- "once a week"
gss$pray[gss$PRAY==3] <- "several times a week"
gss$pray[gss$PRAY==2] <- "once a day"
gss$pray[gss$PRAY==1] <- "several times a day"
gss$pray <- factor(gss$pray)
gss$pray <- relevel(gss$pray, "several times a day")
gss$pray <- relevel(gss$pray, "once a day")
gss$pray <- relevel(gss$pray, "several times a week")
gss$pray <- relevel(gss$pray, "once a week")
gss$pray <- relevel(gss$pray, "lt once a week")
table(gss$pray, gss$PRAY, exclude=NULL)

##                       
##                            0     1     2     3     4     5     6     8     9  <NA>
##   lt once a week           0     0     0     0     0  5469  2239     0     0     0
##   once a week              0     0     0     0  2321     0     0     0     0     0
##   several times a week     0     0     0  4099     0     0     0     0     0     0
##   once a day               0     0  9936     0     0     0     0     0     0     0
##   several times a day      0  9065     0     0     0     0     0     0     0     0
##   <NA>                 28232     0     0     0     0     0     0    96   302     0

First, I created a new variable full of missing values. I then used indexing and boolean statements to replace those missing values with character strings of the correct categories. I then had turned those character string into a factor with the factor command. However, by default, that command will order my categories alphabetically, so I then ran five relevel commands to get the ordering correct. I then run a table command with the exclude=NULL option to include missing values to check myself before I wreck myself. It works, but I am not proud of that code.

Had I bothered to read the help file for factor, I would have realized that I could actually specify ordering of the categories with the levels argument, so I could have simplified my code a little bit by removing the factor and relevel commands and replacing them with the following:

gss$pray <- factor(gss$pray,
                   levels=c("lt once a week","once a week",
                            "several times a week","once a day",
                            "several times a day"),
                   ordered=TRUE)

The ordered option is particularly useful here for running greater than or equal to booleans on factor variables, as I will demonstrate below. Using this code will improve my initial code considerably, but I can still do much better.

My New Approach

My new approach takes advantage of two functions. First, the factor function itself is very flexible and can often be used to recode categorical variables without resort to the bracket and boolean approach. In this case, I can take advantage of the levels and labels argument to directly code my original numeric variable into a categorical variable in one line.

The second function that is essential to date cleaning in R is the ifelse command. This function takes a boolean statement and assigns the value in the second argument if TRUE, and the value in the third argument if FALSE. In this case, I can easily combine the 5 and 6 numeric values from the original variable into just the value of 5 with:

ifelse(gss$PRAY==6, 5, gss$PRAY)

To do the entire re-coding in one line, I just need to wrap a factor function around that code as follows:

gss$pray <- factor(ifelse(gss$PRAY==6, 5, gss$PRAY), 
                   levels=5:1,
                   labels=c("lt once a week","once a week",
                            "several times a week","once a day",
                            "several times a day"), 
                   ordered = TRUE)
table(gss$pray, gss$PRAY, exclude=NULL)

##                       
##                            0     1     2     3     4     5     6     8     9  <NA>
##   lt once a week           0     0     0     0     0  5469  2239     0     0     0
##   once a week              0     0     0     0  2321     0     0     0     0     0
##   several times a week     0     0     0  4099     0     0     0     0     0     0
##   once a day               0     0  9936     0     0     0     0     0     0     0
##   several times a day      0  9065     0     0     0     0     0     0     0     0
##   <NA>                 28232     0     0     0     0     0     0    96   302     0

Just like that, twelve lines of code become one.

You can apply this same trick to data to re-code and collapse data that is already coded as a factor variable. You just need to use cascading ifelse command to collapse and use a character vector for the levels.

To demonstrate, I use my new pray variable to create a pray.simple variable that collapses the data as follows:

• “lt once a week”
• “weekly”: “once a week” and “several times a week”
• “daily”: “once a day” and “several times a day”

I can do this again in a single line of code by using cascading ifelse statements. When the result of an ifelse statement is FALSE, I use another ifelse statement to continue looking for categories that I need.

gss$pray.simple <- factor(ifelse(is.na(gss$pray), NA,
                                 ifelse(gss$pray>="once a day", "daily",
                                        ifelse(gss$pray>="once a week",
                                               "weekly", "lt once a week"))),
                          levels=c("lt once a week", "weekly", "daily"), 
                          ordered=TRUE)
table(gss$pray, gss$pray.simple, exclude=NULL)

##                       
##                        lt once a week weekly daily  <NA>
##   lt once a week                 7708      0     0     0
##   once a week                       0   2321     0     0
##   several times a week              0   4099     0     0
##   once a day                        0      0  9936     0
##   several times a day               0      0  9065     0
##   <NA>                              0      0     0 28630

The first ifelse command filters out the missing values. Then I can use >= booleans (because I used the ordered=TRUE on the factor variable) to partition my valid categories and collapse them into the three that I want. I then define the ordering of the categories by feeding a character vector into levels. The table command shows that everything is ended up where I expected it to be.

Now that my variable is all coded properly, I can look at the trend over time in the frequency of prayer:

p <- prop.table(table(gss$YEAR, gss$pray.simple),1)
matplot(as.numeric(rownames(p)), 100*p, type="l", lty=1, col=rainbow(3),
        lwd=2, las=1, ylab="percent", xlab="year", ylim=c(0,80),
        main="Trend in frequency of prayer in the US,\nGeneral Social Survey")
legend(1972, 80, legend=levels(gss$pray.simple), lty=1, col=rainbow(3),
       ncol=3)

Interpreting interaction terms

McClintock suggests at several points in her response that I fit alternate log-linear models that are distinct from her own and that these models are in some way mis-specified. This claim is a factually incorrect distraction. I estimate the exact same model as McClintock. The fundamental disagreement is over the correct interpretation of parameter estimates in models that allow the effect of beauty to differ for men and women.

McClintock’s estimates from her original article (Table 7) are shown below. The key parameters of interest are what McClintock refers to as “Gender-Symmetric Exchange” and “Gender-Stereotypical Exchange”. These numbers measure the degree to which physical beauty is exchangeable for another partner’s education.

McClintock and I agree on the estimation and interpretation of model 1a. As the name implies, “gender-symmetric exchange” in model 1a assumes that the effect of beauty (i.e. its exchangeability for higher levels of education in a partner) is the same for men and women. These results are in the form of log-odds ratios so the value of 0.524 is both substantively large and statistically significant.

The disagreement arises over how to interpret the numbers in model 1b. The goal of model 1b is to relax the assumption that the beauty effect is the same for men and women. How might one go about this task? You do not need special familiarity with log-linear models to answer this question. Anyone who has taken a first year graduate sequence in statistics should know how to allow effects to vary across categories.

Lets say that you want to know whether the effect of \(x\) on \(y\) in an OLS regression model is different for men and women. Effectively you want two different slopes that we can call \(b_m\) and \(b_w\) for men and women, respectively. You can approach this issue in three different ways:

1. Interact a dummy variable for women with \(x\) in the model. The main effect of \(x\) in this model will give you the effect for men, \(b_m\), and the interaction term will give you the difference, \(b_w-b_m\), in the two effects.

2. Interact a dummy variable for men with \(x\) in the model. The main effect of \(x\) in this model will give you the effect for women, \(b_w\), and the interaction term will give you the difference, \(b_m-b_w\), in the two effects.

3. Create two separate variables that give you the main effects for \(b_m\) and \(b_w\), respectively, but not the difference between the effects.

If you have any two of these values (i.e. a main effect and difference or two main effects) you can derive the third, so the choice of model is primarily driven by ease of interpretation relative to the question at hand. The standard practice is to do either (1) or (2) because researchers often want to directly test whether the difference in effect (i.e. \(H_0:b_m=b_w\)) is statistically significant. This sort of approach can get you into a bit of a pickle, however, because its possible for only one main effect to be statistically distinguishable from zero while the difference between the two effects is statistically indistinguishable from zero. Is it more appropriate in this case to assume that the effects are the same or that one effect is zero and the other non-zero? This situation is exactly what happens in McClintock’s case.

In the table below, I show the parameter estimates for men’s and women’s beauty effects using all three approaches. I also label each approach where it applies to a model used in my response.

For the last three columns, you can derive the numbers for any of the other models from the numbers in a given model because these models are the same. Although each model removes one value, the numbers within each row are identical across columns 2-4, because they measure the same underlying thing. Also note that the gender-symmetric effect from the first column is in between the two separate gender effects from the fourth column, as you would expect. Everything in this table makes sense. The beauty exchange effect for women is substantively large and statistically significant. The beauty exchange effect for men is more uncertain. We cannot confidently say that it is different than zero. However, we also cannot confidently say that it is any different than the effect for women. The model fit statistics (not shown here) prefer the symmetric version of the model, so in the absence of any priors, we should probably assume that there is a real beauty effect of similar magnitude for men and women.²

McClintock uses method (1) in her model 1b. She estimates the main beauty effect for men, and the difference in the beauty effect between men and women. Neither of these effects is statistically significant. In my response, I use method (3) in my model 1c to show that McClintock’s approach left out the most important effect which is the direct effect of beauty for women, i.e. stereotypical exchange. The results for women’s beauty effect are both substantively large and statistically significant. The beauty effect for men is far more equivocal. Its important to note that there is no disagreement between myself or McClintock in how to estimate these values. I am able to reproduce her models 1a and 1b in my comment, and she is able to replicate my model 1c in her response.

The point of this part of my comment was that McClintock used misleading language in both the table and text of her article to describe these effects in a way that made it seem like the beauty effect for women was equivocal when it was clearly unequivocal. I won’t belabor all of those points here, but I do want to address the issue of labeling in her original table because it came up again in McClintock’s response, and suggests to me that she doesn’t fully understand her own models.

If you look again at McClintock’s table above, you will see that she labels the 0.34 effect in model 1b as a “gender-symmetric” effect, whereas I have identified it in my table above and in my comment as the effect for men only. This is the root of our entire disagreement. While it is true that the effect for men is estimated by the same variable that estimates the gender-symmetric effect, the existence of a separate dummy variable for women’s beauty effect means that this variable can no longer be interpreted in the same way in model 1b. One does not need to be technically sophisticated to see that if the model includes a term that identifies women’s beauty effect, then a “gender-symmetric” effect cannot also exist. The entire point of model 1b is to relax the assumption of gender symmetry. Furthermore, the label of “gender stereotypical exchange” in McClintock’s table for the 0.35 number is also misleading. This number is the difference in effect for men and women, not women’s effect alone. One must add the 0.34 and 0.35 together to get the full effect of women’s beauty which is 0.69.

When I wrote the comment, I assumed that these misleading labels were just a result of sloppy but forgivable editing. As someone who does a lot of quantitative work, I know how many versions of a table one can go through and how errors in thinking can easily slip by you. I did not expect McClintock to defend what are clearly misleading labels and I instead figured that she would focus on other aspects of her argument, such as the robustness of the results. Instead, McClintock double downed on this mis-interpretation.

Here is the relevant part of McClintock’s response (Table 1):

She replicates my results exactly but continues to incorrectly label men’s beauty effect (“reverse stereotypical exchange”) in the second column as a “gender symmetric” effect, despite the fact that the number is identical to the “reverse stereotypical” exchange number in the third column. However, she goes even further than that and says explicitly in table note d:

“In a gender-symmetric exchange, either partner may trade socioeconomic status for the other partner’s physical attractiveness. Gullickson lists this parameter twice in his Table 3, as “Gender Symmetric” in Model 1a and as “Men” in Model 1b. Presumably, Gullickson labels the same term differently in Models 1a and 1b because in Model 1b the main “effect” of the gender-symmetric exchange term is interpreted differently due to inclusion of the higher-order (gender-stereotypical) interaction—the main effect in Model 1b is the effect for men; the effect for women is the sum of this main effect and the gender-stereotypical term (described in note e). Despite Gullickson listing this parameter twice, under different names and on different lines, it is the same parameter.” (table 1, note d)

Please read that again twice. Her presumption is correct. I do label them differently because the main effect must be interpreted differently “due to inclusion of the higher-order interaction.” She says outright that the main effect in model 1b is the “effect for men” and that the “effect for women is the sum of the this main effect and the gender-stereotypical term.” Yet, she criticizes me for applying labels that accurately describe the effects in exactly this manner. Within the space of two sentences she directly contradicts herself by saying first that the terms must be interpreted differently and then saying they are the same parameter. I have to conclude that either she is confused about parameter interpretation or she is being deliberately obscurantist.

To help illustrate the problem with her approach let me show the same table I presented above but this time using McClintock’s approach to labeling:

Compare this to my table:

In my table, the numbers for each row stay the same because they measure the same thing. In McClintock’s table, the numbers in the same row jump around from model to model because they measure different things. The labels on the row do not correctly map onto the underlying concepts being measured. It baffles me why McClintock remains committed to this misleading approach when her own words indicate that she knows better.

Gullickson's model == McClintock's model

Other Issues

I don’t want to test the reader’s patience by addressing in detail any of the other issues raised in McClintock’s response, but I do want to make a few brief comments about a few points.

• The difference model and conventional regression model are both linear equations of the same four variables. Therefore, they are not conceptually distinct models with conceptually distinct meanings, but rather different specifications of the same underlying relationships. Mcclintock wants to accept my computations but reject my conclusions on the grounds that the models tell us different things (pg. 2, OnlineFirst). However, the mechanical and conceptuals issues are inseparable in this case. The only substantive difference between the conventional regression models and the difference models as McClintock employed them is that the difference models fail to control for the variables that McClintock correctly argues must be taken into account in order to accurately measure exchange, namely ego partner’s status and the other partner’s beauty. Therefore, by McClintock’s own standards, the difference models are bad models.
• McClintock spends a great deal of time in the response defending the idea that there really is no beauty-status exchange effect. This is somewhat odd given that my comment was specifically directed at problematic model formulation and interpretation and not a direct challenge to her conclusions. It is true that once these issues are taken into account, the evidence of beauty-status exchange is stronger and I tend to think it exists, but I have no strong commitment here, nor am I expecting other scholars to concur. I wish more time had been spent honestly addressing my concerns about methods rather than defending a conclusion that I was not directly addressing.
• Robustness is great. I don’t think what McClintock is doing is robustness checking, however. Proper robust checking means that you address models and measures that give contradictory results in order to understand why the discrepancies occurred. Treating all models and measures as equally valid and then declaring no effect when any of these produce null results is an exercise in motivated reasoning.
• McClintock claims in the response that, for Table 1, “BIC is not decisively improved by adding parameters for beauty-status exchange” (pg. 7, OnlineFirst). She claims this is true of the gender-symmetric model as well as the model that separates the effect by gender. The meaning of the term “decisively” here is quite ambiguous. BIC does prefer the gender-symmetric model to the model with no exchange parameters by a margin of six (1218 vs. 1224). According to the benchmarks suggested by Raftery, a BIC difference of six is right at the boundary between “Positive” and “Strong” results. So why is this difference not “decisive?” I find it hard to believe that any objective researcher would look at the strong substantive size of the effect (68% in the odds ratio), its statistical significance (p-value=0.0008), and the improvement in model fit by BIC and the LRT and reach the conclusion that it should not be in the model.
• The idea that I prioritize statistical significance is laughable. I am an unapologetic Bayesian with a strong distaste for the null ritual. When I see a substantively large but statistically insignificant effect that accords with my vague priors (such as a beauty exchange effect for men, or that the beauty exchange effect for men is smaller than for women), I am happy to think that its probably a real effect rather than zero. McClintock is the one treating a null effect as a zero effect, which is a standard practice among those who fetishize the p-value.

Notes

Same Old Problems, sort of

After many months of experimentation, I can report that while I am impressed by the possibilities of Markdown for writing academic papers, it also still falls somewhat short of the promise that I had for it. By definition, Markdown is designed to offer a minimal set of mark-up options, but the cost of this simplicity is that it can be difficult to get it to do what someone might expect of an academic publication. The answers to these problems typically involve a visit to some StackExchange forum and then fiddling around with latex templates, CSS files, and the like. So, in some sense, I am back in that world of LaTeX where I am trying to figure out how to get my sideways table with multicolumn support and decimal alignment right there, dammit! Nonetheless, I still see a lot of merit in the approach of R Markdown and I intend to continue using it for my manuscripts. After doing some fiddling around, I feel that I have a structure now that works pretty well. I wanted to share what I feel its current shortcomings are and how I have worked around them.

My Solution

The beginning of my solution came from the LaTeX template for R Markdown articles developed by Steven V. Miller. I made some additions and edits to this template for my own purposes, but the template I am using is largely based on his efforts. The latest version of my template is available on GitHub, along with some other tools for compiling the manuscript.

My biggest decision was to separate the main body of my article and the tables and figures into separate R Markdown documents that produce separate PDFs. These separate documents are then concatenated together using pdftk after they are converted to PDF documents. One important addition I made to the template is the ability in the YAML headers to provide a different starting pagination for a document. This allows all of the pagination to match when you combine the final manuscript together from its parts.

I made the decision to keep these documents separate for several reasons. First, many journals require that tables and figures come at the very end after references and I could not figure out how to make this happen in a single document when using a bib file to generate references. Second, this allows me when necessary to easily produce a Word document of the main text of the mansucript and then to separately fiddle around with the tables and figures to get them to work in Word. References will be correct in the Word document and it also seems to do a pretty decent job of converting LaTeX equations. Third, keeping tables and figures separate also makes sensitivity analyses easier. I can make a few changes to the coding procedures (or whatever), rerun the analysis and then save my PDF of the tables and figures under a separate name to preserve my sensitivity analysis for easy comparison.

There are several other options that can be specified in the YAML header. You can see examples of most of these in the starter R Markdown documents on GitHub and the template itself describes them in detail. I added an endnote option that moves footnotes to the end of the paper. I also adjusted the anonymous option so that it produces double-spaced ragged right text.

Here is an example of what a full nicely formatted manuscript would look like under the default settings. The tables were produced with the stargazer package. Here is the same manuscript but with the anonymous option turned on.

This is still a work in progress and I am sure that I will probably fiddle with this a bit more as my current projects make their way through the publication process. However, I am hopeful that there won’t be too much more fiddling. Feel free to take this template and adjust it to your own purposes.

The Models

S&P use panel data where a measurement of race is taken at multiple time points and the race response occasionally varies within individuals over time. This is the racial fluidity that S&P identify. In particular, they are interested in whether this fluidity is associated with changes in social status (e.g. employment, occupational prestige, ever incarcerated). The fundamental insight here (and why the original article generated so much buzz) is that the causal direction of the association between race and social status may in fact run both directions, both of which serve to reinforce the racial hierarchy. S&P actually have multiple papers on this topic, using different data sets and measures of social status. The AJS article uses NLSY79 data and measures social status by characteristics such as unemployment, poverty, marriage, and incarceration. However, regardless of the measure of social status, they employ two modeling approaches to look at the association. First, they run a straight regression model in which racial identification in the later period is predicted by social status in the later period and racial identification in the earlier period.

The idea here is that we can see the effect of social status on the probability of being identified as black in time 2, even while controlling for whether the respondent was identified as black or not in time 1. Controlling for racial identification at time 1 is crucial because otherwise the association between being black in time 2 and social status in time 2 will almost certainly reflect the racial inequality (e.g. black people are more likely to have ever been incarcerated) rather than the racial fluidity that S&P are interested in.

An alternative approach uses a fixed effects panel model.

Here the \(\) fixed effects allow S&P to look at within-person change. So, \(_1\) tells you how a change in social status changes the log-odds that a person will by identified (or self-identify, depending on the measure) as black. Because the fixed effects model controls for all time constant variables, the model effectively controls for phenotypical differences (e.g. skin tone, hair texture) between individuals that might affect both how they identify or are identified and how they are treated.

KD&H’s primary criticism is that the results of S&P’s analysis could easily be driven by measurement error. I feel that they are somewhat vague about the source of such measurement error (a point I will return to below as it forms a significant part of Hannon’s response on Gelman’s blog to my simulation). Lets assume for the moment that we are simply talking about either interviewers or respondents (depending on the data collection format) literally checking the wrong box relative to the box they meant to check or a transcription error when the raw data is compiled. I think everyone can agree that these situations truly would constitute measurement error as the intention of the person giving the response in that particular time and place is not accurately recorded.

KD&H describe a simulation in their comment which seems to show that even in the absence of real effects, a measurement error in race reporting at time 2 of 1.6% can still produce large effects of the size that S&P report. S&P respond by (correctly) pointing out that the simulation should allow for a similar degree of measurement error for race reporting at time 1. When S&P make this correction, the effects that KD&H report are roughly cut in half and substantially below most of the effects that S&P report.

Neither set of authors provide any real discussion of why such a large bias might be produced in the face of such a small amount of measurement error. I can be a bit thick sometimes and it was not immediately clear to me how such measurement bias was produced. So, I built the following simulation mostly to figure it out for myself. If at this point, you just want the tl;dr version, the conclusion is that measurement error could potentially create association in the basic regression model that S&P run, but not the fixed-effects model, because the bias operates in the between-person comparison not the within-person comparison.

The Simulation

sampleSize <- 10000

#two groups, A and D, for advantaged and disadvantaged. What proportion are D?
propD <- 0.1
#base unemployment rate for A
baseUnempA <- 0.1
#ratio of unemployment rate for D
ratioUnemp <- 2

race.time1 <- factor(c(rep("A",round((1-propD)*sampleSize)),
                       rep("D",round(propD*sampleSize))))

#because we start with no fluidity and no measurement error
#race.time2 is identical

race.time2 <- race.time1

#assume double the unemployment rate for Ds as As (20% and 10% respectively)
unemp.time1 <- c(rep(1,round((baseUnempA)*(1-propD)*sampleSize)),
           rep(0,round((1-baseUnempA)*(1-propD)*sampleSize)),
           rep(1,round((baseUnempA*ratioUnemp)*(propD)*sampleSize)),
           rep(0,round((1-(baseUnempA*ratioUnemp))*(propD)*sampleSize)))

baseData <- data.frame(race.time2,race.time1,unemp.time1)

#Create unemp.time2 by  randomly redistributing unemployment within each race group.
#This should give us the same distribution of unemployment by race in each time period
#and of course there can't be a correlation with switching because there is no switching
#in the real data.

baseData$unemp.time2 <- rep(NA, nrow(baseData))
temp <- baseData$unemp.time1[baseData$race.time1=="A"]
temp <- temp[sample(1:length(temp),length(temp),replace=FALSE)]
baseData$unemp.time2[baseData$race.time1=="A"] <- temp
temp <- baseData$unemp.time1[baseData$race.time1=="D"]
temp <- temp[sample(1:length(temp),length(temp),replace=FALSE)]
baseData$unemp.time2[baseData$race.time1=="D"] <- temp

summary(baseData)

##  race.time2 race.time1  unemp.time1    unemp.time2
##  A:9000     A:9000     Min.   :0.00   Min.   :0.00
##  D:1000     D:1000     1st Qu.:0.00   1st Qu.:0.00
##                        Median :0.00   Median :0.00
##                        Mean   :0.11   Mean   :0.11
##                        3rd Qu.:0.00   3rd Qu.:0.00
##                        Max.   :1.00   Max.   :1.00

table(baseData$race.time1, baseData$race.time2)

##
##        A    D
##   A 9000    0
##   D    0 1000

tapply(baseData$unemp.time1, baseData$race.time1, mean)

##   A   D
## 0.1 0.2

tapply(baseData$unemp.time2, baseData$race.time2, mean)

##   A   D
## 0.1 0.2

#reporting error percent
errorProp <- 0.01
#include errors on DV?
dvError <- TRUE
#number of simulations
nSim <- 1000

library(survival)

coefs.basic <- NULL
coefs.fixed <- NULL
tabAA <- NULL
tabDD <- NULL
tabAD <- NULL
tabDA <- NULL

for(i in 1:nSim) {

  errorData <- baseData

  #race.time2
  if(dvError) {
    errors <- sample(1:nrow(errorData), round(errorProp*sampleSize), replace=FALSE)
    temp <- errorData$race.time2[errors]
    temp2 <- rep(NA, length(errors))
    temp2[temp=="A"] <- "D"
    temp2[temp=="D"] <- "A"
    errorData$race.time2[errors] <- temp2
  }

  #race.time1
  errors <- sample(1:nrow(errorData), round(errorProp*sampleSize), replace=FALSE)
  temp <- errorData$race.time1[errors]
  temp2 <- rep(NA, length(errors))
  temp2[temp=="A"] <- "D"
  temp2[temp=="D"] <- "A"
  errorData$race.time1[errors] <- temp2

  #get the mean unemployment by each group of switchers and stayers
  tab <- tapply(errorData$unemp.time2, errorData[,2:1], mean)
  tabAA <- c(tabAA, tab[1,1])
  tabDD <- c(tabDD, tab[2,2])
  tabAD <- c(tabAD, tab[1,2])
  tabDA <- c(tabDA, tab[2,1])

  model <- glm(I(race.time2=="D")~unemp.time2+I(race.time1=="D"), data=errorData,
               family=binomial)

  coefs.basic <- c(coefs.basic, model$coef["unemp.time2"])

  panelData <- rbind(data.frame(race=errorData$race.time1,
                                  unemp=errorData$unemp.time1,
                                  person=1:nrow(errorData),
                                  time=rep(1, nrow(errorData))),
                       data.frame(race=errorData$race.time2,
                                  unemp=errorData$unemp.time2,
                                  person=1:nrow(errorData),
                                  time=rep(2, nrow(errorData))))

  #clogit in the survival library will fit an FE logit
  model <- clogit(I(race=="D")~unemp+strata(as.factor(person)), data=panelData)
  coefs.fixed <- c(coefs.fixed, coef(model)["unemp"])
}

hist(coefs.basic, col="red",
     xlab="effect of unemployment on log odds of identifying as black",
     main="basic regression bias")

summary(coefs.basic)

##    Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
## -0.1781  0.2799  0.3959  0.3984  0.5158  1.0430

hist(coefs.fixed, col="red",
     xlab="effect of unemployment on log odds of identifying as black",
     main="fixed effects bias")

summary(coefs.fixed)

##      Min.   1st Qu.    Median      Mean   3rd Qu.      Max.
## -1.350000 -0.223100  0.000000 -0.003183  0.211900  1.065000

tab <- cbind(c(mean(tabAA),mean(tabDA)),c(mean(tabAD),mean(tabDD)))
rownames(tab) <- c("A","D")
colnames(tab) <- c("A","D")

tab

##           A         D
## A 0.1000189 0.1087715
## D 0.1081952 0.2000196

##            A         D
## A 0.10001088 0.1994540
## D 0.09881213 0.1999546

What now?

Given the results of the simulation, one suggestion might be that we move away from the basic regression model approach in future work toward fixed-effects models that are more robust to potential measurement error. This is a suggestion that KD&H also make.

I think there is also potential for more advanced models here. Both KD&H and Alba et. al. suggest that the model should really only be applied to individuals who are racially ambigious (i.e. that have the potential to be classified in multiple ways). Gelman in his blog post says “For example, I’ll never be counted as “black” no matter how many times I go to jail.” Gelman suggests this might be a source of bias, but I have long thought that S&P are probably underestimating the effect of social status change on racial reporting change, because they are averaging the effects across individuals who vary substantially in their probability to be differently classified. KD&H and Alba et. al. suggest running the models on subsets that are believed to be more racially ambigious (e.g. latinos, multiracial individuals). I think this is an inefficient and overly simplistic approach. I think what we are after here is something like a “treatment on the treated” effect - the effect of switching on those who actually switched, except in this case the switching is the outcome, not the treatment. Some of the innovations in causal modeling on panel data may help provide more clarity in the future.

The Data

The data used here is a 2x2x4x4 table (flattened) of husband’s race (HR) by wife’s race (WR) by husband’s education (HE) by wife’s education (WE). Race is white (1) and black (2). Education is less than high school (1), high school (2), some college (3), and college+ (4). The data come from the US Census 1990, but PLEASE NOTE that I found this data lying around in and cannot vouch for its completeness or representativeness. It is being used for demonstrative purposes and inferences and conclusions should not be drawn from it

mardata <- read.csv("usmardata1990.csv")

Dyadic Exchange Terms

I simply code a set of dummy variables for cases of non-homogamy among interracial couples. This is coded separately by the gender combination of the couple (BM/WF vs. WM/BF) and whether it implies upward or downward marriage for the black partner (not the woman).

mardata$SEBMWFUp <- mardata$HE>mardata$WE & mardata$HR==2 & mardata$WR==1
mardata$SEBMWFDown <- mardata$HE<mardata$WE & mardata$HR==2 & mardata$WR==1
mardata$SEWMBFUp <- mardata$WE>mardata$HE & mardata$HR==1 & mardata$WR==2
mardata$SEWMBFDown <- mardata$WE<mardata$HE & mardata$HR==1 & mardata$WR==2

I also code symmetric terms, that assume the same upward and downward effect.

mardata$SEBMWF <- 0
mardata$SEBMWF[mardata$HE>mardata$WE & mardata$HR==2 & mardata$WR==1] <- 1
mardata$SEBMWF[mardata$HE<mardata$WE & mardata$HR==2 & mardata$WR==1] <- -1
mardata$SEWMBF <- 0
mardata$SEWMBF[mardata$HE<mardata$WE & mardata$HR==1 & mardata$WR==2] <- 1
mardata$SEWMBF[mardata$HE>mardata$WE & mardata$HR==1 & mardata$WR==2] <- -1

Here is the most parsimonious term which assumes both directional symmetry and identical effects for BM/WF and WM/BF couples.

mardata$SE <- mardata$SEBMWF+mardata$SEWMBF

Market Exchange Terms

These terms are synonomous with the educational boundary terms in Gullickson (2006) which are themselves very similar to the terms used by Fu (2001). As I will show below these terms are actually identical to fitting the three way HRxWRxHE and HRxWRxHE (and lower ordered HRxWE and WRxHE) tables, but this particular coding scheme makes the results more interpretable.I use “stairstep” coding here, such that each level of education gets the effect for that level PLUS the effect for lower levels. Using this technique means that each coefficient measures the difference between adjacent levels of education (e.g. college vs. some college) rather than between that level and a fixed reference (e.g. college vs. less than high school). I also included a commented out more traditional dummy formulation for users that prefer that style.

Each term here can be thought of as the increase in the likelihood of interracial marriage when education increases by one level for each race-gender type (i.e. black men, black women,white men, white women).

mardata$EBBM1 <- mardata$HE>1 & mardata$HR==2 & mardata$WR==1
mardata$EBBM2 <- mardata$HE>2 & mardata$HR==2 & mardata$WR==1
mardata$EBBM3 <- mardata$HE>3 & mardata$HR==2 & mardata$WR==1

mardata$EBWF1 <- mardata$WE>1 & mardata$HR==2 & mardata$WR==1
mardata$EBWF2 <- mardata$WE>2 & mardata$HR==2 & mardata$WR==1
mardata$EBWF3 <- mardata$WE>3 & mardata$HR==2 & mardata$WR==1

mardata$EBWM1 <- mardata$HE>1 & mardata$HR==1 & mardata$WR==2
mardata$EBWM2 <- mardata$HE>2 & mardata$HR==1 & mardata$WR==2
mardata$EBWM3 <- mardata$HE>3 & mardata$HR==1 & mardata$WR==2

mardata$EBBF1 <- mardata$WE>1 & mardata$HR==1 & mardata$WR==2
mardata$EBBF2 <- mardata$WE>2 & mardata$HR==1 & mardata$WR==2
mardata$EBBF3 <- mardata$WE>3 & mardata$HR==1 & mardata$WR==2

Geometric mean of HExWE

One of Rosenfeld’s criticisms of prior research is that it did not correctly account for lower-order interaction terms when estimating the status exchange parameter. He argues that the status exchange term is a parameterized coding of the HExWExHRxWR table and thus it is necessary to fit all the three-way and two-way interactions. This includes HRxWRxHE, HRxWRxWE, HRxHExWE, WRxHExWE, HRxWE, and WRxHE. As the appendix to Gullickson and Torche (2014) makes clear, Rosenfeld is wrong about the nature of the dyadic status exchange term. It is actually a parameterized coding of the HExWExHR and HExWExWR tables. As a result, when Rosenfeld includes these terms, his models are overfit, as I will show below. The HRxWRxHE and HRxWRxWE tables are also identical to the market exchange terms coded here which can be thought of as an alternate way of measuring exchange rather than a nuisance control term. For more details, see Gullickson and Torche (2014) and the appendix, Gullickson and Fu (2010), and Kalmijn (2010).

Despite this inherent problems. Rosenfeld’s criticism does reveal one potential shortcoming of the way thesemodels are estimated. When estimating how different the educational assorative mating is for interracial couples (i.e. whether status exchange is occurring), interracial couples are implicitly being compared to the pooled tabled for white and black endogamous couples. But if white and black couples themselves differ in their patterns of ed assortative mating, then the results may be misleading. Probably the best way to handle this is that suggested by Kalmijn (1993) in which the baseline assumption about the educational assortative mating of black/white couples is taken as the geometric mean of the educational asortative mating (HExWE) of white and black endogamous couples. Gullickson and Torche (2014) discusses this in more detail (particularly the appendix). Ultimately we found the results to be similar using the geometric mean (and a few other specifications) as the more naive approach, but it is worth testing on a data set specific basis.

The way of coding this geometric mean is a bit tedious. I fit dummies for each of the nine terms in the HExWE table separately for white endogmous and black endogamous couples and then allow interracial couples to be a 0.5 on each dummy.

mardata$WWHEWE1 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==2 & mardata $WE==2) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==2 & mardata $WE==2)
mardata$WWHEWE2 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==2 & mardata $WE==3) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==2 & mardata $WE==3)
mardata$WWHEWE3 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==2 & mardata $WE==4) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==2 & mardata $WE==4)
mardata$WWHEWE4 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==3 & mardata $WE==2) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==3 & mardata $WE==2)
mardata$WWHEWE5 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==3 & mardata $WE==3) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==3 & mardata $WE==3)
mardata$WWHEWE6 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==3 & mardata $WE==4) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==3 & mardata $WE==4)
mardata$WWHEWE7 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==4 & mardata $WE==2) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==4 & mardata $WE==2)
mardata$WWHEWE8 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==4 & mardata $WE==3) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==4 & mardata $WE==3)
mardata$WWHEWE9 <- (mardata$HR==1 & mardata $WR==1 & mardata $HE==4 & mardata $WE==4) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==4 & mardata $WE==4)

mardata$BBHEWE1 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==2 & mardata $WE==2) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==2 & mardata $WE==2)
mardata$BBHEWE2 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==2 & mardata $WE==3) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==2 & mardata $WE==3)
mardata$BBHEWE3 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==2 & mardata $WE==4) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==2 & mardata $WE==4)
mardata$BBHEWE4 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==3 & mardata $WE==2) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==3 & mardata $WE==2)
mardata$BBHEWE5 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==3 & mardata $WE==3) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==3 & mardata $WE==3)
mardata$BBHEWE6 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==3 & mardata $WE==4) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==3 & mardata $WE==4)
mardata$BBHEWE7 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==4 & mardata $WE==2) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==4 & mardata $WE==2)
mardata$BBHEWE8 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==4 & mardata $WE==3) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==4 & mardata $WE==3)
mardata$BBHEWE9 <- (mardata$HR==2 & mardata $WR==2 & mardata $HE==4 & mardata $WE==4) + 0.5 * (((mardata $HR==1 & mardata $WR==2) | (mardata $HR==2 & mardata $WR==1))  & mardata $HE==4 & mardata $WE==4)

Make sure R treats these as categories and not numbers:

mardata$HE <- as.factor(mardata$HE)
mardata$WE <- as.factor(mardata$WE)
mardata$HR <- as.factor(mardata$HR)
mardata$WR <- as.factor(mardata$WR)

The Models

I first run a baseline model which just fits a general term for racial and educational homogamy (HRxWR and HExWE) as well as account for the differential distribution of education by race (HExHR and WExWR). This model also fits the four marginal terms themselves, of course. Then I fit separate dyadic and market exchange models, plus one that combines them both together. I also run a model with just the straight three way interactions of HRxWRxHE and HRxWRxWE (model.compare) to show that this model is identical to the market exchange model.

model.base <- glm(Freq~HR*WR+HE*HR+WE*WR+HE*WE, family=poisson, data=mardata)

#dyadic - full symmetry in terms of up/down and couple type
model.dyadic.symmetry <- update(model.base, .~.+SE)
round(summary(model.dyadic.symmetry)$coef["SE",],3)

##   Estimate Std. Error    z value   Pr(>|z|)
##      0.181      0.029      6.281      0.000

#dyadic - relax symmetry on couple type but not up/down
model.dyadic.partialsym <- update(model.base, .~.+SEBMWF+SEWMBF)
round(summary(model.dyadic.partialsym)$coef[c("SEBMWF","SEWMBF"),],3)

##        Estimate Std. Error z value Pr(>|z|)
## SEBMWF    0.206      0.034   6.130    0.000
## SEWMBF    0.111      0.056   1.967    0.049

#dyadic - full model allowing different up/down and couple type
model.dyadic.full <- update(model.base, .~.+SEBMWFUp+SEBMWFDown+SEWMBFUp+SEWMBFDown)
round(summary(model.dyadic.full)$coef[c("SEBMWFUpTRUE","SEBMWFDownTRUE","SEWMBFUpTRUE","SEWMBFDownTRUE"),],3)

##                Estimate Std. Error z value Pr(>|z|)
## SEBMWFUpTRUE      0.311      0.055   5.605    0.000
## SEBMWFDownTRUE   -0.095      0.057  -1.664    0.096
## SEWMBFUpTRUE      0.035      0.092   0.382    0.703
## SEWMBFDownTRUE   -0.197      0.101  -1.948    0.051

model.market<- update(model.base, .~.+EBBM1+EBBM2+EBBM3+EBWF1+EBWF2+EBWF3
                                     +EBWM1+EBWM2+EBWM3+EBBF1+EBBF2+EBBF3)
round(summary(model.market)$coef[paste("EBBM",1:3,"TRUE", sep=""),],3)

##           Estimate Std. Error z value Pr(>|z|)
## EBBM1TRUE    0.065      0.092   0.706    0.480
## EBBM2TRUE    0.475      0.057   8.275    0.000
## EBBM3TRUE    0.156      0.075   2.076    0.038

round(summary(model.market)$coef[paste("EBWF",1:3,"TRUE", sep=""),],3)

##           Estimate Std. Error z value Pr(>|z|)
## EBWF1TRUE   -0.327      0.086  -3.825    0.000
## EBWF2TRUE    0.062      0.057   1.093    0.274
## EBWF3TRUE   -0.118      0.072  -1.645    0.100

round(summary(model.market)$coef[paste("EBWM",1:3,"TRUE", sep=""),],3)

##           Estimate Std. Error z value Pr(>|z|)
## EBWM1TRUE   -0.108      0.162  -0.668    0.504
## EBWM2TRUE    0.290      0.098   2.963    0.003
## EBWM3TRUE   -0.386      0.110  -3.511    0.000

round(summary(model.market)$coef[paste("EBBF",1:3,"TRUE", sep=""),],3)

##           Estimate Std. Error z value Pr(>|z|)
## EBBF1TRUE   -0.039      0.182  -0.214    0.831
## EBBF2TRUE    0.283      0.100   2.834    0.005
## EBBF3TRUE    0.080      0.109   0.737    0.461

It can be shown that the market exchange model is just a re-parameterized version of a model with the three-way tables of HWxWRxHE and HRxWRxWE:

model.compare <- update(model.base, .~.+HR*WR*HE+HR*WR*WE)

#models are the same
anova(model.market, model.compare)

## Analysis of Deviance Table
##
## Model 1: Freq ~ HR + WR + HE + WE + EBBM1 + EBBM2 + EBBM3 + EBWF1 + EBWF2 +
##     EBWF3 + EBWM1 + EBWM2 + EBWM3 + EBBF1 + EBBF2 + EBBF3 + HR:WR +
##     HR:HE + WR:WE + HE:WE
## Model 2: Freq ~ HR + WR + HE + WE + HR:WR + HR:HE + WR:WE + HE:WE + WR:HE +
##     HR:WE + HR:WR:HE + HR:WR:WE
##   Resid. Df Resid. Dev Df   Deviance
## 1        27     129.31
## 2        27     129.31  0 4.6612e-12

I also run a model with both, I think this model is too complex and multicollinear to estimate well for the size of the US data

model.both <- update(model.market, .~.+SEBMWFUp+SEBMWFDown+SEWMBFUp+SEWMBFDown)
summary(model.both)

##
## Call:
## glm(formula = Freq ~ HR + WR + HE + WE + EBBM1 + EBBM2 + EBBM3 +
##     EBWF1 + EBWF2 + EBWF3 + EBWM1 + EBWM2 + EBWM3 + EBBF1 + EBBF2 +
##     EBBF3 + SEBMWFUp + SEBMWFDown + SEWMBFUp + SEWMBFDown + HR:WR +
##     HR:HE + WR:WE + HE:WE, family = poisson, data = mardata)
##
## Deviance Residuals:
##     Min       1Q   Median       3Q      Max
## -4.2687  -0.6727  -0.0512   0.8401   3.5696
##
## Coefficients:
##                 Estimate Std. Error  z value Pr(>|z|)
## (Intercept)     9.433917   0.008771 1075.539  < 2e-16 ***
## HR2            -5.248402   0.097723  -53.707  < 2e-16 ***
## WR2            -6.592480   0.189743  -34.744  < 2e-16 ***
## HE2             0.123694   0.011866   10.424  < 2e-16 ***
## HE3            -1.107176   0.017309  -63.964  < 2e-16 ***
## HE4            -3.064602   0.041522  -73.806  < 2e-16 ***
## WE2             0.298178   0.011448   26.046  < 2e-16 ***
## WE3            -0.757925   0.015195  -49.880  < 2e-16 ***
## WE4            -2.791104   0.035573  -78.460  < 2e-16 ***
## EBBM1TRUE       0.044220   0.120767    0.366  0.71424
## EBBM2TRUE       0.440828   0.100567    4.383 1.17e-05 ***
## EBBM3TRUE       0.132652   0.110613    1.199  0.23043
## EBWF1TRUE      -0.286336   0.114631   -2.498  0.01249 *
## EBWF2TRUE       0.095140   0.101745    0.935  0.34975
## EBWF3TRUE      -0.092201   0.107721   -0.856  0.39204
## EBWM1TRUE       0.037637   0.207485    0.181  0.85606
## EBWM2TRUE       0.463988   0.177990    2.607  0.00914 **
## EBWM3TRUE      -0.199226   0.188281   -1.058  0.29000
## EBBF1TRUE      -0.205636   0.225675   -0.911  0.36219
## EBBF2TRUE       0.106623   0.176812    0.603  0.54649
## EBBF3TRUE      -0.104977   0.186340   -0.563  0.57319
## SEBMWFUpTRUE    0.129040   0.113272    1.139  0.25462
## SEBMWFDownTRUE  0.054126   0.115582    0.468  0.63958
## SEWMBFUpTRUE    0.166370   0.199566    0.834  0.40447
## SEWMBFDownTRUE -0.290923   0.204039   -1.426  0.15392
## HR2:WR2         9.415216   0.214532   43.887  < 2e-16 ***
## HR2:HE2        -0.009614   0.020975   -0.458  0.64671
## HR2:HE3        -0.161524   0.022436   -7.199 6.05e-13 ***
## HR2:HE4        -0.946840   0.027690  -34.194  < 2e-16 ***
## WR2:WE2        -0.003369   0.023034   -0.146  0.88372
## WR2:WE3         0.215772   0.023881    9.035  < 2e-16 ***
## WR2:WE4         0.052217   0.028100    1.858  0.06313 .
## HE2:WE2         1.493872   0.014242  104.892  < 2e-16 ***
## HE3:WE2         1.914786   0.019376   98.825  < 2e-16 ***
## HE4:WE2         2.599609   0.043212   60.159  < 2e-16 ***
## HE2:WE3         1.804567   0.017698  101.967  < 2e-16 ***
## HE3:WE3         3.460550   0.021548  160.597  < 2e-16 ***
## HE4:WE3         4.710513   0.043668  107.871  < 2e-16 ***
## HE2:WE4         2.392793   0.037683   63.499  < 2e-16 ***
## HE3:WE4         4.417645   0.039069  113.073  < 2e-16 ***
## HE4:WE4         7.437631   0.054080  137.529  < 2e-16 ***
## ---
## Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
##
## (Dispersion parameter for poisson family taken to be 1)
##
##     Null deviance: 1359384.24  on 63  degrees of freedom
## Residual deviance:     123.07  on 23  degrees of freedom
## AIC: 696.5
##
## Number of Fisher Scoring iterations: 4

Rosenfeld Models

I follow rosenfeld’s protocol of adding in all of the missing two and three way tables and show that his method leads to collinearity such that terms are dropped from the model. This happens because of collinearity between the HExWExHR and HExWExWR terms and the dyadic exchange term.

model.dyadic.symmetry.rosen <- update(model.dyadic.symmetry, .~.+SE+HR*WR*HE+HR*WR*WE+HE*WE*HR+HE*WE*WR)
summary(model.dyadic.symmetry.rosen)

##
## Call:
## glm(formula = Freq ~ HR + WR + HE + WE + SE + HR:WR + HR:HE +
##     WR:WE + HE:WE + WR:HE + HR:WE + HR:WR:HE + HR:WR:WE + HR:HE:WE +
##     WR:HE:WE, family = poisson, data = mardata)
##
## Deviance Residuals:
##      Min        1Q    Median        3Q       Max
## -2.00114  -0.11134   0.00007   0.09103   0.86440
##
## Coefficients: (1 not defined because of singularities)
##              Estimate Std. Error  z value Pr(>|z|)
## (Intercept)  9.442819   0.008901 1060.919  < 2e-16 ***
## HR2         -5.515703   0.132445  -41.645  < 2e-16 ***
## WR2         -6.459140   0.189711  -34.047  < 2e-16 ***
## HE2          0.110730   0.012251    9.038  < 2e-16 ***
## HE3         -1.124848   0.017972  -62.588  < 2e-16 ***
## HE4         -3.105487   0.042970  -72.272  < 2e-16 ***
## WE2          0.286471   0.011776   24.327  < 2e-16 ***
## WE3         -0.773848   0.015838  -48.860  < 2e-16 ***
## WE4         -2.831289   0.037708  -75.084  < 2e-16 ***
## SE          -0.238405   0.513277   -0.464 0.642306
## HR2:WR2      9.445999   0.205511   45.963  < 2e-16 ***
## HR2:HE2      0.799361   0.513035    1.558 0.119209
## HR2:HE3      1.024105   0.482226    2.124 0.033695 *
## HR2:HE4      0.728863   0.695441    1.048 0.294611
## WR2:WE2     -0.067885   0.574681   -0.118 0.905968
## WR2:WE3      0.278550   0.584551    0.477 0.633704
## WR2:WE4      0.952901   0.977790    0.975 0.329786
## HE2:WE2      1.508189   0.014876  101.383  < 2e-16 ***
## HE3:WE2      1.941309   0.020216   96.028  < 2e-16 ***
## HE4:WE2      2.637738   0.044730   58.971  < 2e-16 ***
## HE2:WE3      1.828234   0.018611   98.234  < 2e-16 ***
## HE3:WE3      3.484150   0.022600  154.163  < 2e-16 ***
## HE4:WE3      4.757091   0.045287  105.044  < 2e-16 ***
## HE2:WE4      2.440390   0.039969   61.057  < 2e-16 ***
## HE3:WE4      4.460603   0.041393  107.762  < 2e-16 ***
## HE4:WE4      7.511727   0.056616  132.678  < 2e-16 ***
## WR2:HE2     -0.740162   0.517347   -1.431 0.152520
## WR2:HE3     -0.279076   0.479371   -0.582 0.560452
## WR2:HE4     -0.453587   0.710676   -0.638 0.523313
## HR2:WE2     -0.090518   0.566985   -0.160 0.873158
## HR2:WE3      0.148923   0.578828    0.257 0.796959
## HR2:WE4     -0.467346   0.976898   -0.478 0.632367
## HR2:WR2:HE2  0.075881   0.190844    0.398 0.690921
## HR2:WR2:HE3 -0.688182   0.194748   -3.534 0.000410 ***
## HR2:WR2:HE4 -0.465144   0.217321   -2.140 0.032326 *
## HR2:WR2:WE2  0.288773   0.206524    1.398 0.162037
## HR2:WR2:WE3 -0.049173   0.209064   -0.235 0.814048
## HR2:WR2:WE4 -0.018368   0.230452   -0.080 0.936474
## HR2:HE2:WE2 -0.687546   0.191297   -3.594 0.000325 ***
## HR2:HE3:WE2 -0.316237   0.625629   -0.505 0.613229
## HR2:HE4:WE2 -0.571651   0.752693   -0.759 0.447569
## HR2:HE2:WE3 -1.112013   0.534309   -2.081 0.037414 *
## HR2:HE3:WE3 -0.740565   0.252233   -2.936 0.003324 **
## HR2:HE4:WE3 -0.797097   0.751690   -1.060 0.288960
## HR2:HE2:WE4 -0.439894   0.267458   -1.645 0.100027
## HR2:HE3:WE4 -0.451155   0.128731   -3.505 0.000457 ***
## HR2:HE4:WE4 -0.602608   0.680483   -0.886 0.375855
## WR2:HE2:WE2  0.529706   0.194919    2.718 0.006576 **
## WR2:HE3:WE2 -0.019024   0.632898   -0.030 0.976020
## WR2:HE4:WE2 -0.062874   0.765853   -0.082 0.934570
## WR2:HE2:WE3  0.873657   0.534613    1.634 0.102220
## WR2:HE3:WE3  0.473865   0.258185    1.835 0.066451 .
## WR2:HE4:WE3  0.012654   0.764538    0.017 0.986794
## WR2:HE2:WE4 -0.060050   0.244462   -0.246 0.805960
## WR2:HE3:WE4        NA         NA       NA       NA
## WR2:HE4:WE4 -0.521754   0.692958   -0.753 0.451488
## ---
## Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
##
## (Dispersion parameter for poisson family taken to be 1)
##
##     Null deviance: 1.3594e+06  on 63  degrees of freedom
## Residual deviance: 1.5464e+01  on  9  degrees of freedom
## AIC: 616.89
##
## Number of Fisher Scoring iterations: 4

The same holds for the other dyadic models but I don’t show them for brevity

I show that dropping out HExWExHR and HExWExWR resolves the problem.

model.dyadic.symmetry2 <- update(model.dyadic.symmetry.rosen, .~.-HE*WE*HR-HE*WE*WR+HE*WE+HR*HE+WR*WE)
summary(model.dyadic.symmetry2)

##
## Call:
## glm(formula = Freq ~ SE + HE + WE + HR + WR + HR:WR + HE:WE +
##     HR:HE + WR:WE + HR:WR:HE + HR:WR:WE, family = poisson, data = mardata)
##
## Deviance Residuals:
##     Min       1Q   Median       3Q      Max
## -4.2768  -0.6448  -0.0025   0.9059   3.5663
##
## Coefficients:
##               Estimate Std. Error  z value Pr(>|z|)
## (Intercept)  9.4336620  0.0087707 1075.582   <2e-16 ***
## SE           0.0896727  0.0921363    0.973   0.3304
## HE2          0.1240076  0.0118625   10.454   <2e-16 ***
## HE3         -1.1064333  0.0173026  -63.946   <2e-16 ***
## HE4         -3.0637522  0.0415174  -73.794   <2e-16 ***
## WE2          0.2986655  0.0114452   26.095   <2e-16 ***
## WE3         -0.7577437  0.0151914  -49.880   <2e-16 ***
## WE4         -2.7912246  0.0355690  -78.473   <2e-16 ***
## HR2         -5.1859816  0.0913501  -56.770   <2e-16 ***
## WR2         -6.6378141  0.1833072  -36.211   <2e-16 ***
## HR2:WR2      9.3981456  0.2059242   45.639   <2e-16 ***
## HE2:WE2      1.4931995  0.0142350  104.896   <2e-16 ***
## HE3:WE2      1.9139129  0.0193652   98.832   <2e-16 ***
## HE4:WE2      2.5988140  0.0432090   60.145   <2e-16 ***
## HE2:WE3      1.8045918  0.0176897  102.014   <2e-16 ***
## HE3:WE3      3.4596951  0.0215402  160.616   <2e-16 ***
## HE4:WE3      4.7097796  0.0436655  107.861   <2e-16 ***
## HE2:WE4      2.3927802  0.0376795   63.503   <2e-16 ***
## HE3:WE4      4.4175471  0.0390664  113.078   <2e-16 ***
## HE4:WE4      7.4370806  0.0540787  137.523   <2e-16 ***
## HE2:HR2     -0.0116255  0.1134661   -0.102   0.9184
## HE3:HR2      0.2408140  0.1694825    1.421   0.1554
## HE4:HR2     -0.4581314  0.2400019   -1.909   0.0563 .
## WE2:WR2     -0.1067811  0.1921746   -0.556   0.5785
## WE3:WR2      0.3248699  0.2278745    1.426   0.1540
## WE4:WR2      0.1699295  0.2906272    0.585   0.5587
## HE2:HR1:WR2 -0.0480788  0.1739408   -0.276   0.7822
## HE3:HR1:WR2  0.3128585  0.2135509    1.465   0.1429
## HE4:HR1:WR2  0.0006849  0.2793518    0.002   0.9980
## HE2:HR2:WR2  0.0020019  0.1150646    0.017   0.9861
## HE3:HR2:WR2 -0.4022965  0.1707187   -2.356   0.0184 *
## HE4:HR2:WR2 -0.4886577  0.2413877   -2.024   0.0429 *
## WE2:HR2:WR1 -0.2614800  0.1092373   -2.394   0.0167 *
## WE3:HR2:WR1 -0.1269414  0.1681540   -0.755   0.4503
## WE4:HR2:WR1 -0.1754218  0.2377134   -0.738   0.4605
## WE2:HR2:WR2  0.1034074  0.1933343    0.535   0.5927
## WE3:HR2:WR2 -0.1091439  0.2289138   -0.477   0.6335
## WE4:HR2:WR2 -0.1178039  0.2917812   -0.404   0.6864
## ---
## Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
##
## (Dispersion parameter for poisson family taken to be 1)
##
##     Null deviance: 1359384.24  on 63  degrees of freedom
## Residual deviance:     128.37  on 26  degrees of freedom
## AIC: 695.79
##
## Number of Fisher Scoring iterations: 4

The resulting model is equivalent to a model with both a dyadic and market exchange term

model.equivalent <- update(model.market, .~.+SE)

#models are the same
anova(model.dyadic.symmetry2, model.equivalent)

## Analysis of Deviance Table
##
## Model 1: Freq ~ SE + HE + WE + HR + WR + HR:WR + HE:WE + HR:HE + WR:WE +
##     HR:WR:HE + HR:WR:WE
## Model 2: Freq ~ HR + WR + HE + WE + EBBM1 + EBBM2 + EBBM3 + EBWF1 + EBWF2 +
##     EBWF3 + EBWM1 + EBWM2 + EBWM3 + EBBF1 + EBBF2 + EBBF3 + SE +
##     HR:WR + HR:HE + WR:WE + HE:WE
##   Resid. Df Resid. Dev Df   Deviance
## 1        26     128.37
## 2        26     128.37  0 1.0829e-11

Geometric Mean Models

Here I just rerun the dyadic and market exchange models with the geometric mean baseline rather than the pooled HE*WE baseline. The results are fairly consistent with what we had before for BM/WF couples, but not WM/BF couples.

model.base.geo <- glm(Freq~HR*WR+HE*HR+WE*WR
                      +WWHEWE1+WWHEWE2+WWHEWE3+WWHEWE4+WWHEWE5+WWHEWE6+WWHEWE7+WWHEWE8+WWHEWE9
                      +BBHEWE1+BBHEWE2+BBHEWE3+BBHEWE4+BBHEWE5+BBHEWE6+BBHEWE7+BBHEWE8+BBHEWE9,
                    family=poisson, data=mardata)

model.dyadic.symmetry.geo <- update(model.base.geo, .~.+SE)
round(summary(model.dyadic.symmetry.geo)$coef["SE",],3)

##   Estimate Std. Error    z value   Pr(>|z|)
##      0.094      0.032      2.909      0.004

model.dyadic.partialsym.geo <- update(model.base.geo, .~.+SEBMWF+SEWMBF)
round(summary(model.dyadic.partialsym.geo)$coef[c("SEBMWF","SEWMBF"),],3)

##        Estimate Std. Error z value Pr(>|z|)
## SEBMWF    0.127      0.037   3.462    0.001
## SEWMBF    0.002      0.059   0.026    0.979

model.dyadic.full.geo <- update(model.base.geo, .~.+SEBMWFUp+SEBMWFDown+SEWMBFUp+SEWMBFDown)
round(summary(model.dyadic.full.geo)$coef[c("SEBMWFUpTRUE","SEBMWFDownTRUE","SEWMBFUpTRUE","SEWMBFDownTRUE"),],3)

##                Estimate Std. Error z value Pr(>|z|)
## SEBMWFUpTRUE      0.228      0.058   3.955    0.000
## SEBMWFDownTRUE   -0.021      0.059  -0.349    0.727
## SEWMBFUpTRUE     -0.084      0.094  -0.889    0.374
## SEWMBFDownTRUE   -0.099      0.103  -0.966    0.334

model.market.geo <- update(model.base.geo, .~.+EBBM1+EBBM2+EBBM3+EBWF1+EBWF2+EBWF3
                                     +EBWM1+EBWM2+EBWM3+EBBF1+EBBF2+EBBF3)
round(summary(model.market.geo)$coef[paste("EBBM",1:3,"TRUE", sep=""),],3)

##           Estimate Std. Error z value Pr(>|z|)
## EBBM1TRUE   -0.023      0.094  -0.245    0.807
## EBBM2TRUE    0.443      0.066   6.758    0.000
## EBBM3TRUE   -0.117      0.115  -1.020    0.308

round(summary(model.market.geo)$coef[paste("EBWF",1:3,"TRUE", sep=""),],3)

##           Estimate Std. Error z value Pr(>|z|)
## EBWF1TRUE   -0.246      0.087  -2.820    0.005
## EBWF2TRUE    0.072      0.062   1.175    0.240
## EBWF3TRUE    0.012      0.092   0.127    0.899

round(summary(model.market.geo)$coef[paste("EBWM",1:3,"TRUE", sep=""),],3)

##           Estimate Std. Error z value Pr(>|z|)
## EBWM1TRUE   -0.029      0.163  -0.181    0.856
## EBWM2TRUE    0.321      0.103   3.124    0.002
## EBWM3TRUE   -0.112      0.140  -0.798    0.425

round(summary(model.market.geo)$coef[paste("EBBF",1:3,"TRUE", sep=""),],3)

##           Estimate Std. Error z value Pr(>|z|)
## EBBF1TRUE   -0.105      0.182  -0.576    0.565
## EBBF2TRUE    0.264      0.103   2.574    0.010
## EBBF3TRUE   -0.036      0.122  -0.297    0.767

model.both.geo <- update(model.market.geo, .~.+SEBMWFUp+SEBMWFDown+SEWMBFUp+SEWMBFDown)
summary(model.both.geo)

##
## Call:
## glm(formula = Freq ~ HR + WR + HE + WE + WWHEWE1 + WWHEWE2 +
##     WWHEWE3 + WWHEWE4 + WWHEWE5 + WWHEWE6 + WWHEWE7 + WWHEWE8 +
##     WWHEWE9 + BBHEWE1 + BBHEWE2 + BBHEWE3 + BBHEWE4 + BBHEWE5 +
##     BBHEWE6 + BBHEWE7 + BBHEWE8 + BBHEWE9 + EBBM1 + EBBM2 + EBBM3 +
##     EBWF1 + EBWF2 + EBWF3 + EBWM1 + EBWM2 + EBWM3 + EBBF1 + EBBF2 +
##     EBBF3 + SEBMWFUp + SEBMWFDown + SEWMBFUp + SEWMBFDown + HR:WR +
##     HR:HE + WR:WE, family = poisson, data = mardata)
##
## Deviance Residuals:
##      Min        1Q    Median        3Q       Max
## -2.04068  -0.15854  -0.00307   0.08040   1.29960
##
## Coefficients:
##                  Estimate Std. Error  z value Pr(>|z|)
## (Intercept)     9.4424651  0.0089015 1060.771  < 2e-16 ***
## HR2            -5.2992451  0.0992333  -53.402  < 2e-16 ***
## WR2            -6.6419054  0.1916985  -34.648  < 2e-16 ***
## HE2             0.1113715  0.0122500    9.092  < 2e-16 ***
## HE3            -1.1244246  0.0179676  -62.581  < 2e-16 ***
## HE4            -3.1048894  0.0429522  -72.287  < 2e-16 ***
## WE2             0.2869685  0.0117756   24.370  < 2e-16 ***
## WE3            -0.7731030  0.0158353  -48.821  < 2e-16 ***
## WE4            -2.8312119  0.0377131  -75.072  < 2e-16 ***
## WWHEWE1         1.5073958  0.0148737  101.346  < 2e-16 ***
## WWHEWE2         1.8270943  0.0186076   98.191  < 2e-16 ***
## WWHEWE3         2.4401371  0.0399709   61.048  < 2e-16 ***
## WWHEWE4         1.9407072  0.0202114   96.021  < 2e-16 ***
## WWHEWE5         3.4833896  0.0225929  154.181  < 2e-16 ***
## WWHEWE6         4.4603494  0.0413926  107.757  < 2e-16 ***
## WWHEWE7         2.6369640  0.0447113   58.978  < 2e-16 ***
## WWHEWE8         4.7560636  0.0452671  105.067  < 2e-16 ***
## WWHEWE9         7.5114299  0.0566029  132.704  < 2e-16 ***
## BBHEWE1         1.3410881  0.0502215   26.703  < 2e-16 ***
## BBHEWE2         1.5779047  0.0585859   26.933  < 2e-16 ***
## BBHEWE3         1.9362962  0.1155999   16.750  < 2e-16 ***
## BBHEWE4         1.5986861  0.0694740   23.011  < 2e-16 ***
## BBHEWE5         3.2093970  0.0736196   43.594  < 2e-16 ***
## BBHEWE6         4.0051074  0.1216050   32.935  < 2e-16 ***
## BBHEWE7         1.9926851  0.1731084   11.511  < 2e-16 ***
## BBHEWE8         3.9602726  0.1708851   23.175  < 2e-16 ***
## BBHEWE9         6.3820746  0.1947376   32.773  < 2e-16 ***
## EBBM1TRUE      -0.0768475  0.1208813   -0.636 0.524955
## EBBM2TRUE       0.3702178  0.1052368    3.518 0.000435 ***
## EBBM3TRUE      -0.1798681  0.1407477   -1.278 0.201268
## EBWF1TRUE      -0.1700799  0.1153182   -1.475 0.140246
## EBWF2TRUE       0.1432551  0.1023114    1.400 0.161458
## EBWF3TRUE       0.0741508  0.1208766    0.613 0.539584
## EBWM1TRUE       0.0836009  0.2055211    0.407 0.684173
## EBWM2TRUE       0.4612129  0.1771260    2.604 0.009218 **
## EBWM3TRUE       0.0421616  0.2045247    0.206 0.836678
## EBBF1TRUE      -0.2424182  0.2239950   -1.082 0.279142
## EBBF2TRUE       0.1226603  0.1755297    0.699 0.484677
## EBBF3TRUE      -0.1889397  0.1926369   -0.981 0.326688
## SEBMWFUpTRUE    0.1713216  0.1123854    1.524 0.127406
## SEBMWFDownTRUE -0.0002799  0.1147010   -0.002 0.998053
## SEWMBFUpTRUE    0.1163524  0.1968910    0.591 0.554555
## SEWMBFDownTRUE -0.2600328  0.2019226   -1.288 0.197821
## HR2:WR2         9.4082094  0.2166726   43.421  < 2e-16 ***
## HR2:HE2         0.1420302  0.0436537    3.254 0.001140 **
## HR2:HE3         0.0616976  0.0644029    0.958 0.338065
## HR2:HE4        -0.1823256  0.1702354   -1.071 0.284160
## WR2:WE2         0.1358971  0.0421421    3.225 0.001261 **
## WR2:WE3         0.3853543  0.0519410    7.419 1.18e-13 ***
## WR2:WE4         0.4693778  0.1136058    4.132 3.60e-05 ***
## ---
## Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
##
## (Dispersion parameter for poisson family taken to be 1)
##
##     Null deviance: 1.3594e+06  on 63  degrees of freedom
## Residual deviance: 2.6313e+01  on 14  degrees of freedom
## AIC: 617.74
##
## Number of Fisher Scoring iterations: 4