`compute_rank_mahalanobis` ignores index argument

[benthestatistician]

...in the event that there's an exact matching constraint in force. The function presently computes and returns a distance for each treatment/control combination, even when provided a list of specific treatment-control matching possibilities for which a distances is needed.

to do's:

• If possible, fix it in compute_rank_mahananobis
• If not possible, workaround on R side
• Add a test case to test.rank.mahal.R

[benthestatistician]

In the example in #122 , we have

> length(within@rows)
[1] 4889857

whereas compute_rank_mahalanobis has give a result of length

length(dists)
[1] 22887076

matching the product of the overall number of rows and columns.

> within@dimension

[1] 2252 10163

[benthestatistician]

@jwbowers since you've caught the rank_mahalanobis bug, would you be willing to help out w/ writing of test cases?

I figured I'd start by writing out some tests where you do a rank_mahalanobis calculation by pre-computing the ranks in R, then applying ordinary Mahalanobis. That led me to try the following, which does not work, but which is more likely to represent a misunderstanding on my part of what rank_mahalanobis is trying to do than a problem with the code. I.e., maybe you can help me improve it w/o much effort.

test_that("compute_rank.mahal results match ordinary Mahalanobis's", {
   nr <- 10L
   z <- integer(nr)
    z[sample(1:nr, nr / 2L)] <- 1L

   X <- as.matrix(1L:nr)
   df <- data.frame(z = z, X)
   expect_equivalent(match_on(z~., data=df, method="rank_mahalanobis"),
                     match_on(z~., data=df, method="mahalanobis")
                     )
}
)

(Once I get something like this going, should be easy to write test cases for the combo of exact matching and rank Mahalanobis.)

[benthestatistician]

In tests/testthat/test.rank.mahal.R, compute_rank_mahalanobis is tested against the rank Mahalanobis function that Rosenbaum has posted to his site. I confirmed that their results match up in this example also, even as they differ from those of compute_mahalanobis.

The likely cause of the difference is underlying differences in how the covariance is being computed. optmatch has always calculated the covariances needed for Mahalanobis distance computations by pooling covariances in treatment and control groups. In defining rank-based Mahalanobis, Rosenbaum uses an unpooled covariance. Anyway there's no indication of anything amiss, other than the problem with compute_rank_mahalanobis noted at the top of this ticket. We'll need another strategy for test cases.

[kkbrum]

@benthestatistician FYI, this "ignoring" the "within" argument during the actual computation process is causing issues for the new version of student matching for ADSY (since the data is really too large when "within" is ignored). It won't help me (I'll work around it), but I would advocate for actually fixing this issue. At the very least, a note in the "match_on" documentation page about the futility of "within" for "method = rank_mahalanobis" would be nice.

[benthestatistician]

Thanks for taking the trouble to track this down and post a comment on it, @kkbrum. I think I resorted to a shortcut because I wasn't confident I'd be able to update @nullsatz 's code in src/r_smahal.* and src/smahal.*.

Now that we've got Josh back on the team, though: Josh, could you look into enabling the index argument of the rank mahanalobis computation, so that when a BISM is requested it only has to compute and store the within-block distances? My workaround was to use the existing rank mahalanobis routines to compute a distance for each treatment control pair. In sufficiently large matching problems this is no good.