Ben

Currently SubProbInfo doesn't attempt to describe subproblems' structural restrictions (min.controls etc). That was intentional, to avoid binding the class too tightly to full matching, as opposed to other matching schemes...

I no longer agree w/ my previous (5/28/2019) comment on this thread: subproblems of problems A and B should be treated as the same iff it's a context where A...

Three more things: 1\. I suspect the SubProblemInfo's should store dual and primal values, not dual and Lagrangian values: it's the dual-primal gap that bounds the regret. So, unless we...

@adamrauh I'm inviting your contributions here, toward closing the four open to-do's noted in the comments of this issue. The first of the four, about renaming classes, should probably come...

1. I like the modularization you've added. 1'\. Rather than writing a `update.SubProbInfo()` method, I'd encourage coming up with a name that doesn't suggest that it's an SPI update method,...

Implemented for a single subproblem in 0bdc6f0. Still to do: - [x] Make `evaluate_*` functions work just as well with a (distance, MCFSolutions) pair combining multiple subproblems, none of which...

When this is ready it can go into the summary.optmatch routine (#173).

As noted in [this comment](https://github.com/markmfredrickson/optmatch/issues/166#issuecomment-751888537) to #166, for performance reasons we should also - [ ] consider whether there'd be performance savings to combining `evaluate_lagrangian()` and `evaluate_dual()` into a single...

Looking back on this work, I can't think of anything we actually need the Lagrangian value for. Presently in the master branch it's being calculated and stored, as `lagrangian_value` in...

NB: redefining the SubProblemInfo class calls for updates in `setClass("SubProbInfo", )` and `setValidity("SubProbInfo", )`, over in MCFSolutions.R. (And for running devtools::document() after that.)