Automatically verify whether constructors should be re-run

[mnwhite]

This issue is reproduced from communications among team members.

---

MNWHITE writes:

A recurring snag for new HARK users is that when they change a "primitive" parameter like PermShkStd, this does not automatically flow through to IncShkDstn when the model is solved. The "cheap" fix is to have solve() automatically run construct() before doing other work unless the directive construct=False is passed. This can be computationally expensive if the user forgets to do that even when re-constructing isn't necessary.

The more comprehensive solution that Chris asked for is to have a system of checking whether constructors need to be re-run because something has changed. I think this is feasible. The idea is that each AgentType instance would have some "private" dictionary that stores all of the inputs used on a past constructor call, as well as a reference to the constructor itself. Whenever construct is called, it compares current vs previous values for each object it would construct; if nothing has changed, it doesn't run.

Implementing this would also help resolve a potential "weird dependency" or "dependency conflict" problem with constructors.

---

ALANLUJAN91 writes:

Python properties might be useful here: https://realpython.com/python-property/

---

LLORRACC writes:

A while ago, we put a fair amount of work into attaching to our Distribution creators exactly the information that would be needed to recompute the discretization. We did that precisely for the purpose of enabling this functionality: When a previously created Distribution object is queried for its discretization of the stochastic process, it can (itself) check whether the discretization matches the parameter values with which it has now been called.

Alan is the wizard on the structure of these Distribution objects.

---

MNWHITE writes:

That's for distributions, but not all constructed inputs are distributions. Moreover, the discrete distributions carry information about the continuous distribution they approximate, but not the function/constructor that built them. The system I'm describing here is meant to be universally applicable.

And when we did that distribution work, we got it upside down. The "true" distribution is an attribute of the discretization, but we should have had the discretization be an attribute of the true distribution.

---

LLORRACC writes:

If [those constructed objects] don't contain info about the function/constructor that built them, we need to add that information.

My definition of "true" here is the model we think of ourselves as approximating. Remember my goal of automated robustness testing: If the "true" model is a lognormal truncated at 3 std devs, then the code can automatically loop over the number of gridpoints until adding more gridpoints does not change the result. The distributions code was created precisely with that goal in mind.

---

MNWHITE writes:

To be make the point more broadly: not all constructed inputs are objects that can even have information added to them. They could be a list of numbers, or an array (or list of arrays), or even a single number.

To the extent your point is that you want the information about how something got made to exist and be accessible after instantiation, I can do that, and it's what I'm proposing. I don't think it's possible nor a good idea to have "provenance data" right on every single object.