the "whiteboard problem"

[sbenthall]

Throughout HARK, the AgentType object is being used like a whiteboard.

Mathematical objects are assigned as attributes to self willy-nilly. This leads to an unstructured namespace that is hard to understand.

As a further refactoring step, aligned with #660 and other issues:

• compartmentalizing the math so that more of the board is "erased" between operations
• when possible, the math "inputs" into functions get passed in as arguments rather than getting drawn from self.

This will encapsulate the code in a way that makes it easier to decompose and refactor.

[sbenthall]

Another way to address this is to introduce more namespaces.

A good target for this might be the many *Dstn variables that get created. I.e. IncomeDstn, RiskyDstn.
These then get sampled for shocks.

This connects to the idea that maybe these distributions should be passed in directly as parameters: #620

But other namespaces could be introduced for, for example, mathematical objects used for checkConditions, or those used when computing solutions.

[sbenthall]

I had an idea that's a little goofy, but which may be a good short term solution.

This is to add a property, "boards", to the AgentType object.
Then a new "whiteboard" can be made for the mathematical work of a particular method by doing this:

self.boards["myContext"] = (board := {})

It can also be written without the Python 3.8 walrus operator but you get the idea.

Then in that method one can assign properties to the board:

board.MPCnow = #whatever

If you really want to inspect the mathematical work, then you can find the whiteboard where it was written and look at it. But this way it won't clutter the top-level namespace.

I would much prefer a functional programming orientation and I think we need to get there for complete mathematization of Frames. But I think this would be an improving to the current HARK model code that would help get us to the Frame architecture by structuring the data little more.

[sbenthall]

What about a decorator (@etc) for importing a namespace into the scope of a method so that the mathematical objects are available for use?

[sbenthall]

Punting to 1.1 for time reasons.