Ben

The version of subdim() that we implemented can't handle BISMs with no eligible matches in any subclass. ```r Z

@josherrickson any comments on my proposal just above? (It goes somewhat against a suggestion you made [further up in the same comment thread](https://github.com/markmfredrickson/optmatch/issues/129#issuecomment-315338351), a couple years back.)

Notes: - It calls for e.g. `sum( unlist( matched.distances(mymatch, mydist) ) )`, which has at least 2 nonintuitive aspects (the need to pass a distance; `unlist()`). - One natural place...

wouldn't this hypothetical user's computer be happier if she instead did ```{r} match_on(treatment ~ x1 + x2, data = mydata, within=exactMatch(treatment ~ mypairs, data = mydata) ) ``` or the...

I wonder if we're seeing some issues in the wild relating to calling the wrong solver. the issue statement suggests to me that _unless_ I've specifically asked for the fallback...

Getting back to the original issue of testing for fallback vs main solver (and away from the side-issue of whether error messages not related to this issue do too much...

Road map: vignettes/dual-MCF-solution.Rmd in branch issue54-hinting. As of 34e2474 , this compiles into [dual-MCF-solution.pdf](https://github.com/markmfredrickson/optmatch/files/3179856/dual-MCF-solution.pdf).

For `MCFSolutions` objects I don't think we actually need `object@matchables`: the info in there is available as ```r object@nodes %>% dplyr::filter(kind!="bookkeeping") %>% dplyr::select(name, kind,subproblem) ``` Unless we might need a...

Another adjustment we'll need: the user's treatment/control dichotomy may differ from the parallel dichotomy as understood by the solver, i.e. "T(**f**)" vs "C(**f**)" in this picture:  That's b/c this...

As Mark noted on #166, joining of NodeInfo and ArcInfo tables (e.g. functions in R/complementarySlackness.R) along a factor would be aided by having the two factors have a common set...