***This page is completely outdated and must be refreshed.***

This page describes how to use Python libraries for macroeconomic modelling, allowing to extend Dynare functionalities.

# Python ressources

- Formal calculus
- Numerical computing
numpy : contains an efficient implementation of matrix processing whose performance is close to matlab

scipy : set of scientific routines including optimization routines

pyrex and psyco (included in scipy) can speedup computations. The first allows to write C extensions in a python-like syntax, while the second performs just-in-time compilation of python functions.

- Other
epydoc generates online documentation from inline documentation

mlabwrap uses the Matlab Engine to interact with Matlab. It permits to send and retrieve data, as well as to call Matlab function from Python.

rpy : low-level access to statistical program R permitting to call every R functions as python functions.

py2exe packs a python program with all its libraries in a single windows executable which includes the interpreter.

pymaclab another attempt to use python estimate DSGE models. It uses its own Modfile format which is then parsed by Python.

qz.py : a wrapper around LAPACK's qz routine.

eclipse and pydev provide a good development environment for Python.

IPython is a python console which may prove useful when learning new commands. In particular

`command?`returns incode documentation for command`command`.

# Writing/extending modfiles in Python

There is a small prototype in python, called Dolo available at www.mosphere.fr which can be called from the command line for quick processing or conversion (not functional) or can be imported as python library. Its initial aim was to extend Dynare to deal with the formal representation of objects.

Here is the code of ramsey.py, which translates ramst.mod into python code. It is run by the standard Python interpreter. Line-by-line explication follows.

```
1 ####################
2 # Model Definition #
3 ####################
4
5 from daredare import *
6
7 set_variables("k c")
8 set_exovariables("z")
9 set_shocks("x")
10 set_parameters("alpha beta gamma delta aa")
11
12 equations = [
13 Equation(c + k , (1 - delta)*k(-1) + k(-1)**alpha*(1 + z)*aa),
14 Equation(0 , -1/(1 + beta)*c(1)**(-gamma)*(1 - delta + k**(-1 + alpha)*(1 + z(1))*aa*alpha) + c**(-gamma)),
15 Equation(z(1),x(1))
16 ]
17
18 parameters_values = {
19 alpha : 0.5,
20 gamma : 1*alpha,
21 delta : 0.02,
22 beta : 0.05,
23 aa : 0.5
24 }
25
26 covariances = matrix([[0.01]])
27
28 init_values = {
29 k:(1/aa/alpha*(beta + delta))**(1/(-1 + alpha)),
30 c:k**alpha*aa - delta*k
31 }
32
33 ####################
34 # Model processing #
35 ####################
36
37 model = Model("ramsey",lookup=True)
38 model.check_all('uhlig')
39
40 solver = Solver(model,lookup=True)
41
42 ss = solver.find_steady_state()
43 print(ss)
44
45 res = solver.solve_with_uhligs_toolkit()
46
47
48 print('PP',res.PP)
49 print('QQ',res.QQ)
```

## Language extension (for model definition)

On the very first line of this code `from daredare import *` imports the library. The second block

creates formal objects "k,c,z" which all derive of the same class `Variable`. This class is a subclass of the standard Sympy class `Symbol`, which only adds the possibility to take lags or leads with a function call : for instance `k(1)` returns another Variable whose formal name is ` k_{+1} `. ` k.lag ` returns the lag so that ` k(-k.lag) ` or equivalently `k.p()` will always return a variable with lag 0.

Parameters are of the class `Parameter` which derives also from `Symbol` but cannot be called.

It should be noted that, a priori, the formal object, and the Python reference name which is used by the compiler are to different things. For instance,

will print : `x**2/y`. In this respect the functions like `set_variables` are notable because instead of returning the created objects, they also add references to the interpreter context, with the same names as the variables. They also add the python names `variables`,`shocks`,`exovariables`,`parameters`. The next block

defines equations. The object Equation is a child of Sympy's `Equality` object. It contains the expression as well as some attributes as (optionally) equation name, expectational nature, and other information that could be computed later. Three remarks :

unfortunately we cannot write

`x+y == z`because in python`==`must always return true or false (see Sympy mailing list).to convert from/to matlab, you only have to convert

`*`from/to`^`. For instance, if`eq`is a python formal expression,`str(eq).replace('==','=').replace('**','^')`will give the valid Dynare expression.- every sympy operations on equalities are available
`printing.latex(eq)`(or`printing.mathml(eq)`will return the latex (or mathml) representation of the equality`preview(eq)`will launch an viewer to preview the latexified output`eq.rhs.diff(c)`will return the right side of the equation differentiated with respect to c`eq.rhs.subs(c(1),c)`will replace`c(1)`by`c`in the right side

To define initial values, we use dictionaries whose whose keys are the symbolic and whose values are either numeric or symbolic. Dictionaries values are accesses using brackets.

```
1 init_values[k]
```

will return the symbolic expression `k:(1/aa/alpha*(beta + delta))**(1/(-1 + alpha))`

## Processing model(s)

In the next lines we create the model and check its consistency :

Note the option `lookup=True`. Normally, in the scope of a function, you can only access local variables and arguments. `model` function uses python's introspection routines to lookup in the stack for the lists `variables`,`exovariables`,`shocks`,`parameters` and `equations` and to attach them to the object `model`. We have already used this magic in the functions `set_variables`. Then, equations can be accessed with `model.equations`.

The second line checks for model consistency. So far the formal objects we have created are totally agnostic to modelling conventions which vary across software and users. The instance function `check_all` makes some basic checks to see if the model is consistent with one formulation. As for now, it accepts two arguments `'uhlig'` and `'dynare'`. Note that `exovariables` as it is defined in Uhlig's conventions don't exist in Dynare. `shocks` denote independent random variables and correspond to the `varexo` statement in Dynare.

A solver object depends on a model and maps a set of parameters to a decision rule. Here, we have only one value for this set, so we can get them from the initial declaration using `lookup=True`. The second statement is useless when Dynare is the destination. It returns a dictionary containing the steady state. Many steps are involved :

- Initial values and initial parameters are computed from the formal declarations. This involve, solving a triangular system, which is easy.
- Formal equations are converted into a numeric python function which is added to interpreting context at runtime.
- This function is optimized to return the steady state

The last lines compute the decision rule. In the case of Uhlig, it returns two matrix representing the decision rules.

If the model were written following Dynare convention, we would have called :

to get the results from octave or

to get the results from Matlab. For Octave, we write a modfile and send it to a new session while we use the Matlab engine to send it to Matlab with the added benefit that we can do many calculations without clearing the Matlab workspace each time.

## Import and export

### Modfile import

Instead of rewriting a model that is already in a modfile, we can import it to Python with the command `import_modfile` and process the model as seen previously. The command adds all variables of the model block that are founds in the modfile to python interpreter. It doesn't even try to understand other elements of modfile syntax such as macrocommands and additional processing commands.

Given that a `ramst.mod` file exists, the following code does just that and replaces all occurrences of `c` by `log(c/css)` where css is a parameter

```
1 import_modfile('ramst.mod')
2
3 # following two lines could be collapsed in a new function add_parameter('css') which would do :
4 css = Parameter('css')
5 parameters.append( css )
6
7 for i in range(equations):
8 equations[i] = equations[i].replace(c,log(c/css))
9
10 ###########################
11 # End of model definition #
12 ###########################
```

### Modfile export

A solver object can be exported to a modfile and written to a file using :

### XML serialization

A solver object can be serialized to XML using

```
1 xmltext = solver.toxml()
```

The resulting string is a quick prototype where stricly needed informations are stored (equations are stored unparsed in Dynare format) it could be adapted easily to communicate with Dynare or another program using a simple standardized file.