Lunch meeting 2014 Oct 03

Review of Friday Conversation

Initial conversation notes:

Pierre Louis Lyons has some work on Mean Field Games. (Pablo: See http://www.princeton.edu/~moll/HACT.pdf). Chris mentioned some papers he sent to Pablo (ask about).

Also discussed possible advantages and disadvantages of Python vs Julia as a backend for something like 'Dynare 2.0'. (Pablo: let's say informally Dynare NG.) Dynare is currently at version 4.x) Julia is a completely JIT language, similar syntax to Matlab, extremely fast. Python's compiled options lag behind -- Numba does not have much (well-documented) object-oriented support and is still a bit immature and PyPy does not have many of the optimization libraries.

(Nate's note: Jython is one of the only other viable compiled options for Python. Probably not ready for prime-time. Details after the notes below.) (Pablo: Dropbox/Pyston is also worth mentioning here). (Pablo: when we come to the meeting we should have a relatively clear idea about the platform we want to work on. Or the Matlab guys will strike back immediately.)

An ideal approach for Dynare 2.0 may be something like the following: have a Dynare GUI which calls a Dynare kernel (Pablo has a Qt/Enamel/IPython widgets project underway: github:econforge:dyngui ). The first-pass kernel would be Matlab, but eventually could switch to C++/Julia/etc. The goal would be that the user sees no difference in performance before/after the switch, and simply continues to interact with the front-end as before. (Pablo: This transition for Dynare is by no way official. Michel has never even said that there would be a rewrite of Dynare.)

Pablo notes that, while interest is currently in Julia, nearly all of his current code base is in Python. (Pablo: bridges like pyjulia/pycall make me think that the infrastructure (gui, web, ...) should remain in Python, but that many components could be written in Julia.)

This suggests one topic: which language for micro-econ-related heterogeneous-agent models, vs language for backend of Dynare 2.0. (Pablo: not sure I understand it anymore).

This also launches us into the topics of the lunch outline: Topics for the Workshop.

Topic for the Workshop (1): A Descriptive Language for the "Top-Down" Approach

And some discussion of Workshop (2): Bottom-up approach

Something that has arisen at the IMF: the model language for Dynare is perhaps too restrictive for these types of purposes.

For a Dynare 2.0 which handles micro-style heterogeneous-agent models, how would we want the user to describe the model? There are basically two approaches:

• describe a set of equations which outline the model. Not necessarily a system of equations in a linear algebra sense (eg Ramsey models), but rather the equations which describe the consumer problem, arbitrage restrictions, market clearing, etc.

  • This could be presented in something like a YAML / JSON file
  • The program would pull this in and interpret it, set up everything and execute.

• alternatively, an "object-oriented" approach: the code for each type of agent is described in a class-style structure.

  • Perhaps abstract classes and an API is used to outline the setup; the researcher simply writes code to match the API (essentially "fills in" some spots in an example piece of code.)
  • Perhaps as small reusable libraries. (sounds like bottom-up)

[Nate's note: almost sounds like the two descriptions above are for top-down vs bottom-up.] [Pablo: I don't completely agree. An object oriented approach needs very careful ex ante thinking about how the components are going to interact and which is responsible for waht. (OO design). The way I understood the bottom-up approach, is that we write many necessary pieces as unconnected as possible, and tries to use them to see which uses emerge.]

[Discussion about different meanings of "system of equations" to describe the model.]