I’m currently experiencing what I believe to a bug with MatchIt while using
R 3.3.2 (64bit) on a windows machine. In my case the full matching is not
optimal and in fact can lead to a negative balance improvement (balance
worsening) for the covariates specified.
Here is a toy example I made to illustrate the issue:
####################
library(MatchIt)
treat = c(0 , 0, 0, 0, 0, 0, 1, 1, 1, 1, 1)
x = c(10,20,30,40,100,102, 11, 21, 31, 41, 101)
data = as.data.frame( cbind( treat, x) )
matched = matchit( treat ~ x, data=data, distance = "mahalanobis", method
="full")
x[which( matched$subclass == 1)]
x[which( matched$subclass == 2)]
x[which( matched$subclass == 3)]
x[which( matched$subclass == 4)]
x[which( matched$subclass == 5)]
summary(matched)
####################
The optimal match in this case is clear: 10 is to be matched with 11, 20
with 21, 30 with 31, 40 with 41, and 101 with 100 and 102. This is indeed
the match given by other matchit distances (logit, log, etc.) and gives a
91% balance improvement in the covariate x.
However, with the mahalanobis distance I get a rather strange matching. For
example, 40 is matched with 11, while 102 is matched with 41. The percent
balance “improvement” is -76%.
I am wondering if this is the intended behavior for matchit, and if there
is a work around to provide the matching one would expect for these data.
Best regards,
Guillaume
Show replies by date