Provide more interpretation of results

[sglyon]

As noted in the end of issue 13, dolo could provide more basic analysis of the solution and simulation results. For easy formatting in an ipython notebook, we could represent these other items with pandas.

One idea is to add an option to each of the solution routines like full_output=False. If the user were to pass True here the solution routine could generate some moments and statistics about the solution and automatically display them in a pandas DataFrame.

What ideas do we have for things that would be useful?

[albop]

So the basic idea would be to add that option to solve_decision_rule() ? I wonder whether this one is of sufficiently high level. I would like to separate as much as possible user-friendly function from algorhmic code. This one is actually on the frontier. Why don't we introduce a solve_model(model) function whose main argument could be a model (or even a string) and which would return a dictionary of results (including d.r. and moments) with the option to display them ? Do you want to give it a try ?

[sglyon]

Sure I will have a go at it.

Before I can do much I need to understand more about what dr contains.

Specifically, I don't know what ['g_ee', 'g_a', 'g_ae', 'g_ss', 'g_e', 'g_aa', 'ev'] are.

Also, what types of things would be useful to have dolo report if solve_model() is called? I find that I usually want autocorrelations, a correlation matrix, steady_state values, moments from the simulation (mean, std, var). What else would you like to have returned?

I agree that returning a dictionary of pandas.DataFrame objects is a great idea.

[albop]

Here is what dr contains. Denote by a_t the vector of variables of the model in the order of declarations and by e_t the vector of exogenous shocks. Assume there are n variables and m shocks.Then the decision rule is a function a_t = g(a_{t-1}, e_t, s) where s a parameter scaling the expectation of future shocks. Then all the g_ arrays are multidimensional objects representing the derivatives.

Here are the dimensions of these objects: g_a: n times n g_e: n times m g_ae: n times n times m . (g_ae[i,j,k] represents \frac{$\partial g_ }{\partial a_j \partial a_k})

I think it is a very straightforward representation, even if not the most efficient.

A lot of coefficients are actually 0. If you get the indices of state variables with something like [model.variables.index(v) for v in model.state_variables] then you can certainly reduce the number of coefficients to be printed. If I remember well you can access the model where the d.r. comes from with dr.model.

(just edited : ev is the list of eigenvalues, that can be computed using g_a. TODO : keep and print the eigenvalues of the generalized eigenvalue problem as it gives clues about model misspecifications)

[albop]

I quickly ran a modfile, and here is what is printed :

• model summary (corresponds to model.check_consistency(verbose=True)
• matrix of covariance of exogenous shock (part of model summary)
• policy and transition functions (coefficients of the d.r.)
• theoretical moments
• variance decomposition
• correlations
• autocorrelations

Variance decomposition may not be extremely useful to us in the short term. Others are pretty straightforward.

Now there is a little question about what should and shouldn't be coded in dolo. We should probably make the exact computations ourselves in the first order case. Then for higher order cases, given that we use simulations to compute the results, we could use routines from pandas. I have very little experience with this software so I don't know the pros and cons.

[albop]

Another quick thought from today's breakfast : as we agree that results of the solve_model should be a dictionary of results, then a quick and elegant way of printing the result, could simply consist in implementing a display function for the dictionary (or rather for a custom subclass). Then the command solve_model() would return this "results" object which would be nicely printed. And if well done, this results objects could be used in different places where we return statistics. Only drawback I can see with this approach : if computations are very long, then you have to wait until the end to have something printed on the screen. In any case, the solve_global() should provide user with reports on its progress by default (with print() ?)