Rewrite specification helpers

[janosg]

Now that respy is much more flexible, we still want to be able to reproduce the classical Keane Wolpin models easily. Therefore I propose to rewrite the specification helpers. They should now have the arguments:

• model (str): One of kw97_base, kw97_extended, kw94 (potentially we need more, one would have to go over both papers and see which models they estimate.
• n_types (int): number of types

The helper function should then generate a params DataFrame and an options dict that reproduces that can be used to estimate the corresponding model.

Potentially we could have similar helper functions to get the datasets for those models.

[tobiasraabe]

Regarding the kw94 examples, they are hybrids between kw94 and kw97. Some of the covariates are not mentioned in kw94 or can be simplified (e.g. kw94 does not distinguish between college and high school tuition). This makes it hard to compare the implemention with the original.

• is_return_high_school and is_return_not_high_school should become net_tuition.

[tobiasraabe]

What we essentially need is reworking generate_random_model() and its dependencies. I propose to make a distinction between

1. Specification helpers generate the structure of a parameter specification (choices, lagged choices, shocks, covariates, etc.). The helpers can be used to generate a completely random model or to extend models from papers.
2. A function which takes a parameter specification like "kw_94_one" or a random model and adds noise to the parameters. This function is also useful to quickly get models as a starting point to re-estimate replicated models. Make test suite more random and add add_noise_to_params, move to Github Actions, etc.. #320 includes a draft of the function called add_noise_to_params.

Other issues we have on our list:

• Related to Invalid initital conditions #322 where random models have initial conditions which allow for zero experience in a choice and having the same choice as the previous choice. We need to overcome this by
  1. Generating better random models.
  2. Maybe we can automatically generate some core state space filters. Related to Expose check for invalid states to users. #298.

[tobiasraabe]

Unfortunately, in German. Can be translated if necessary.

Ich habe überlegt, dass generate_random_model umzuschreiben. Was würdet ihr davon halten, wenn man in die Funktion eine Liste mit dictionaries gibt, die jeweils ein Model feature beschreiben. ZB

model = [
    {"feature": "choice", "name": "a", "wage": True},          # Implicitly exp=True
    {"feature": "choice", "name": "edu", "experience": True, "maximum_experience": 20},  # Implicitly wage=False
    {"feature": "choice", "name": "home"},                     # Implicitly all False
]

Oder man könnte hier "feature" und "name" direkt zusammen legen zu

{"choice": "a"}

, was aber schon weniger explizit ist.

Die anderen würden dann so aussehen (mache mit dem ersten Design weiter):

model = [
    {"feature": "lagged_choice", lags=1},
    {"feature": "observed_variable", "name": "ability", "levels": range(3)},
    {"feature": "exogenous_process", "name": "weather", "levels": ["rainy", "sunny"]},
    {"feature": "unobserved_heterogeneity", "n_types": 3},
]

Um ein Feature auszuschalten, würde ich einen andere key einfügen. Vielleicht

{"feature": "exogenous_process", "available": False}  # Implicitly True

Dann würde das generate_random_model eine Liste von diesen Dicts erhalten und je nach
feature die passende Funktion aufrufen.

Man müsste vielleicht ein wenig auf die Reihenfolge achten. ZB erst choices und dann lagged choices.

What are your thoughts, @peisenha @mo2561057? Especially the naming should be very intuitive.