[WIP] New parameters handling

[sbenthall]

(This PR currently builds on #442, which should be merged first)

Work towards new parameter handling, see #446

At this time, this PR shows how to replace the hard-coded ConsumptionParameters.py with a Python file that reads the parameters from a YAML configuration file. This file can be used in the same way as the old file. (There are a few remaining changes to make before reaching parity with the old version, such as handling the setting of config parameters to be numpy arrays).

[llorracc]

Looks like it is failing a Travis check. (Thank you Travis!)

[MridulS]

yaml needs to be added in requirements @sbenthall :)

[sbenthall]

This is going to continue to break until I fix all the parsing issues.

I believe the bugs are coming from cases where ConsumptionParameters.py defined a parameter as a python object (such as a numpy array), which is not something you can parse directly out of a YAML file.

I wonder if I should keep trying to prototype this solution?

I believe it is the right path to go down, myself.
It sheds light on some design choices that I think could use attention.

For example, when we think about "model parameters", maybe we ought to be separating the kinds of
parameters that refer to terms with economic meaning from the kinds of parameters that refer to the executing of an approximating simulation. (I brought this up here).

[llorracc]

For example, when we think about "model parameters", maybe we ought to be

separating the kinds of parameters that refer to terms with economic meaning from the kinds of parameters that refer to the executing of an approximating simulation. (I brought this up here). I think this is a very good point; these two categories of things do need to be clearly distinguished from each other somehow. Whether it is by one set of them being defined in yaml files and another set by arguments passed when functions are invoked, or in some other way, I'm not sure; but you're right in identifying this as an important distinction we should be making). Do you have a proposal for how to handle it?

…

On Mon, Dec 23, 2019 at 7:28 PM Sebastian Benthall ***@***.***> wrote: This is going to continue to break until I fix all the parsing issues. I believe the bugs are coming from cases where ConsumptionParameters.py defined a parameter as a python object (such as a numpy array), which is not something you can parse directly out of a YAML file. I wonder if I should keep trying to prototype this solution? I believe it is the right path to go down, myself. It sheds light on some design choices that I think could use attention. For example, when we think about "model parameters", maybe we ought to be separating the kinds of parameters that refer to terms with economic meaning from the kinds of parameters that refer to the executing of an approximating simulation. (I brought this up here <#446 (comment)>). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#462?email_source=notifications&email_token=AAKCK77L3ITPHVWZFVWG773Q2FJTDA5CNFSM4J5PAQWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHSFTEI#issuecomment-568613265>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK72CZUDFYUIH6AMASW3Q2FJTDANCNFSM4J5PAQWA> .

-- - Chris Carroll

[sbenthall]

It looks like these may be designated as "options" in Dolang

https://github.com/EconForge/dolo/blob/master/examples/models/consumption_savings.yaml

[llorracc]

We definitely need to discuss this more. Let's tee it up for the call this Thursday.

[sbenthall]

For a different approach to the parameter handling issue, see #466

I think #466 is a better approach to start with; using .yaml can come later.

[llorracc]

Let's plan to discuss this on Thursday.

…

On Sun, Jan 5, 2020 at 9:26 PM Sebastian Benthall ***@***.***> wrote: For a different approach to the parameter handling issue, see #466 <#466> I think #466 <#466> is a better approach to start with; using .yaml can come later. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#462?email_source=notifications&email_token=AAKCK762RKLTGPZILRQ5TZLQ4KJE5A5CNFSM4J5PAQWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIEHK3Y#issuecomment-570979695>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK7YAWBUH4MUQ6LSLMZDQ4KJE5ANCNFSM4J5PAQWA> .

-- - Chris Carroll

[sbenthall]

I'm going to close this PR.
Using a yaml file for parameters is something I'd like to work on again, but I think now it's better approaching it in a slightly different way.