A Solver class allowing for inspection

[sbenthall]

The Solver methods currently do not subclass a common class.

If there were such a class, it would be easier to have boilerplate methods for inspecting them, including:

• reporting what the control variables being solved are
• relevant state
• equations useful for solving (such as an arbitrage equation)

Then the Solver subclasses could take arguments from the model definition when initialized.

[sbenthall]

@mnwhite I was thinking about taking a crack at this and then reviewing the issue was reminded that you are interested in removing "object oriented solvers" in favor of solver methods.

So before picking at this I wanted to check in.

Of course, the solver could be a callable object, maybe being the best of both worlds.

The main issue I'm seeing is that we would like a 'magic solver' that is able to take in functions defined in a model specification. There currently isn't an architecture that supports that.

I wonder if you've given any thought to, if you could do it all over again, how you would design solvers for HARK.

[mnwhite]

I'm archiving this and tagging it as part of the HARK 1 roadmap; no real discussion happened here. We're actively working on having model data be tied to the solver itself.