Use objects for solver outcomes, not errors and tuples #101
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TLDR;
SolverResultclass that can be used as the output for any methods we implement to solve casual problems.Why?
A couple of reasons.
The first is that the SGD method was already returning a tuple of 4 values, the order of which was both somewhat arbitrary and going to be a pain to enforce consistently across the codebase if we ever add any more solver methods. Having a simple container object that can store this information for later access is cleaner to return.
The second being that we don't want to rely on throwing errors when one of our solver methods fails to converge (or encounters some other problem), since we may want to take action based on this result. (This is particularly relevant to the Quadratic Penalty Method). Instead, we should just bundle all the relevant information into the object that's returned, which can indicate whether or not the solver method was successful on inspection of an attribute.