1166 lines
45 KiB
TeX
1166 lines
45 KiB
TeX
\documentclass{beamer}
|
|
%\documentclass[draft]{beamer}
|
|
%\documentclass[handout]{beamer}
|
|
|
|
|
|
\mode<handout>
|
|
{
|
|
\usepackage{pgfpages}
|
|
\pgfpagesuselayout{4 on 1}[a4paper,border shrink=3mm,landscape]
|
|
\usetheme{Madrid}
|
|
\usecolortheme{seagull}
|
|
}
|
|
|
|
\mode<beamer>
|
|
{
|
|
\usetheme{Madrid}
|
|
\setbeamercovered{transparent}
|
|
}
|
|
|
|
|
|
\usepackage[english]{babel}
|
|
\usepackage[utf8]{inputenc}
|
|
|
|
\usepackage{times}
|
|
|
|
|
|
\title{The Dynare Preprocessor}
|
|
|
|
\author[S. Villemot]{Sébastien Villemot}
|
|
|
|
\institute{CEPREMAP}
|
|
|
|
\date{October 19, 2007}
|
|
|
|
\AtBeginSection[]
|
|
{
|
|
\begin{frame}{Outline}
|
|
\tableofcontents[currentsection]
|
|
\end{frame}
|
|
}
|
|
|
|
\begin{document}
|
|
|
|
\begin{frame}
|
|
\titlepage
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{General overview}
|
|
\begin{center}
|
|
\includegraphics[width=11cm]{overview.png}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Outline}
|
|
\tableofcontents
|
|
\end{frame}
|
|
|
|
\section{Introduction to object-oriented programming in C++}
|
|
|
|
\begin{frame}
|
|
\frametitle{Object-oriented programming (OOP)}
|
|
\begin{itemize}
|
|
\item Traditional way of programming: a program is a list of instructions (organized in functions) which manipulate data
|
|
\item OOP is an alternative programming paradigm that uses \alert{objects} and their interactions to design programs
|
|
\pause
|
|
\item With OOP, programming becomes a kind of modelization: each object of the program should modelize a real world object, or a mathematical object (\textit{e.g.} a matrix, an equation, a model...)
|
|
\item Each object can be viewed as an independent little machine with a distinct role or responsibility
|
|
\item Each object is capable of receiving messages, processing data, and sending messages to other objects
|
|
\pause
|
|
\item Main advantage of OOP is \alert{modularity}, which leads to greater reusability, flexibility and maintainability
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Object}
|
|
\framesubtitle{Definition and example}
|
|
\begin{itemize}
|
|
\item An \alert{object} is the bundle of:
|
|
\begin{itemize}
|
|
\item several variables (called its \alert{attributes}), which modelize the characteristics (or the state) of the object
|
|
\item several functions (called its \alert{methods}) which operate on the attributes, and which modelize the behaviour of the object (the actions it can perform)
|
|
\end{itemize}
|
|
\pause
|
|
\item Example: suppose we want to modelize a coffee machine
|
|
\begin{itemize}
|
|
\item The coffee machine (in real life) is a box, with an internal counter for the credit balance, a slot to put coins in, and a button to get a coffee
|
|
\item The corresponding object will have one attribute (the current credit balance) and two methods (one which modelizes the introduction of money, and the other the making of a coffee)
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{A coffee machine}
|
|
\framesubtitle{Class definition}
|
|
\begin{block}{C++ header file (\texttt{CoffeeMachine.hh})}
|
|
\begin{scriptsize}
|
|
\begin{verbatim}
|
|
class CoffeeMachine {
|
|
public:
|
|
int credit;
|
|
CoffeeMachine();
|
|
void put_coin(int coin_value);
|
|
void get_coffee();
|
|
};
|
|
\end{verbatim}
|
|
\end{scriptsize}
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item A \alert{class} is a template (or a blueprint) of an object
|
|
\item Collectively, the attributes and methods defined by a class are called \alert{members}
|
|
\item A class definition creates a new \alert{type} (\texttt{CoffeeMachine}) that can be used like other C++ types (\textit{e.g.} \texttt{int}, \texttt{string}, ...)
|
|
\item In C++, class definitions are put in header files (\texttt{.hh} extension)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{A coffee machine}
|
|
\framesubtitle{Method bodies}
|
|
\begin{block}{C++ source file (\texttt{CoffeeMachine.cc})}
|
|
\begin{scriptsize}
|
|
\begin{verbatim}
|
|
void CoffeeMachine::put_coin(int coin_value)
|
|
{
|
|
credit += coin_value;
|
|
cout << "Credit is now " << credit << endl;
|
|
}
|
|
|
|
void CoffeeMachine::get_coffee()
|
|
{
|
|
if (credit == 0)
|
|
cout << "No credit!" << endl;
|
|
else {
|
|
credit--;
|
|
cout << "Your coffee is ready, credit is now " << credit << endl;
|
|
}
|
|
}
|
|
\end{verbatim}
|
|
\end{scriptsize}
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Methods can refer to other members (here the two methods modify the \texttt{credit} attribute)
|
|
\item Method bodies are put in source files (\texttt{.cc} extension)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Constructors and destructors}
|
|
\begin{itemize}
|
|
\item In our class header, there is a special method called \texttt{CoffeeMachine()} (same name than the class)
|
|
\item It is a \alert{constructor}: called when the object is created, used to initalize the attributes of the class
|
|
\end{itemize}
|
|
\begin{block}{C++ source file (\texttt{CoffeeMachine.cc}, continued)}
|
|
\begin{scriptsize}
|
|
\begin{verbatim}
|
|
CoffeeMachine::CoffeeMachine()
|
|
{
|
|
credit = 0;
|
|
}
|
|
\end{verbatim}
|
|
\end{scriptsize}
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item It is possible to create constructors with arguments
|
|
\item It is also possible to define a \alert{destructor} (method name is the class name prepended by a tilde, like \texttt{$\sim$CoffeeMachine}): called when the object is destroyed, used to do cleaning tasks (\textit{e.g.} freeing memory)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Instantiation and method invocation}
|
|
\begin{block}{Program main function}
|
|
\begin{scriptsize}
|
|
\begin{verbatim}
|
|
#include "CoffeeMachine.hh"
|
|
|
|
int main()
|
|
{
|
|
CoffeeMachine A, B;
|
|
|
|
A.put_coin(2);
|
|
A.get_coffee();
|
|
|
|
B.put_coin(1);
|
|
B.get_coffee();
|
|
B.get_coffee();
|
|
}
|
|
\end{verbatim}
|
|
\end{scriptsize}
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Creates two machines: at the end, \texttt{A} has 1 credit, \texttt{B} has no credit and refused last coffee
|
|
\item \texttt{A} and \texttt{B} are called \alert{instances} of class \texttt{CoffeeMachine}
|
|
\item Methods are invoked by appending a dot and the method name to the instance variable name
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Dynamic instantiation with \texttt{new}}
|
|
\begin{block}{Program main function}
|
|
\begin{scriptsize}
|
|
\begin{verbatim}
|
|
#include "CoffeeMachine.hh"
|
|
|
|
void main()
|
|
{
|
|
CoffeeMachine *A;
|
|
|
|
A = new CoffeeMachine();
|
|
|
|
A->put_coin(2);
|
|
A->get_coffee();
|
|
|
|
delete A;
|
|
}
|
|
\end{verbatim}
|
|
\end{scriptsize}
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Here \texttt{A} is a pointer to an instance of class \texttt{CoffeeMachine}
|
|
\item Dynamic creation of instances is done with \texttt{new}, dynamic deletion with \texttt{delete} (analogous to \texttt{malloc} and \texttt{free})
|
|
\item Since \texttt{A} is a pointer, methods are called with \texttt{->} instead of a dot
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Access modifiers}
|
|
\begin{itemize}
|
|
\item In our coffee machine example, all attributes and methods were marked as \texttt{public}
|
|
\item Means that those attributes and methods can be accessed from anywhere in the program
|
|
\item Here, one can gain credit without putting money in the machine, with something like \texttt{A.credit = 1000;}
|
|
\item The solution is to declare it \alert{private}: such members can only be accessed from methods within the class
|
|
\end{itemize}
|
|
\begin{block}{C++ header file (\texttt{CoffeeMachine.hh})}
|
|
\begin{scriptsize}
|
|
\begin{verbatim}
|
|
class CoffeeMachine {
|
|
private:
|
|
int credit;
|
|
public:
|
|
CoffeeMachine();
|
|
void put_coin(int coin_value);
|
|
void get_coffee();
|
|
};
|
|
\end{verbatim}
|
|
\end{scriptsize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Interface}
|
|
\begin{itemize}
|
|
\item The public members of a class form its \alert{interface}: they describe how the class interacts with its environment
|
|
\item Seen from outside, an object is a ``black box'', receiving and sending messages through its interface
|
|
\item Particular attention should be given to the interface design: an external programmer should be able to work with an class by only studying its interface, but not its internals
|
|
\item A good design pratice is to limit the set of public members to the strict minimum:
|
|
\begin{itemize}
|
|
\item enhances code understandability by making clear the interface
|
|
\item limits the risk that an internal change in the object requires a change in the rest of the program: \alert{loose coupling}
|
|
\item prevents the disruption of the coherence of the object by an external action: principle of \alert{isolation}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Why isolation is important}
|
|
\begin{itemize}
|
|
\item Consider a class \texttt{Circle} with the following attributes:
|
|
\begin{itemize}
|
|
\item coordinates of the center
|
|
\item radius
|
|
\item surface
|
|
\end{itemize}
|
|
\item If all members are public, it is possible to modify the radius but not the surface, therefore disrupting internal coherence
|
|
\item The solution is to make radius and surface private, and to create a public method \texttt{changeRadius} which modifies both simultaneously
|
|
\item \textit{Conclusion:} Creating a clear interface and isolating the rest diminishes the risk of introducing bugs
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Inheritance (1/2)}
|
|
|
|
\begin{block}{Matrices and positive definite matrices}
|
|
\begin{scriptsize}
|
|
\begin{columns}[t]
|
|
\begin{column}{4.8cm}
|
|
\begin{verbatim}
|
|
class Matrix
|
|
{
|
|
protected:
|
|
int height, width;
|
|
double[] elements;
|
|
public:
|
|
Matrix(int n, int p,
|
|
double[] e);
|
|
virtual ~Matrix();
|
|
double det();
|
|
};
|
|
\end{verbatim}
|
|
\end{column}
|
|
\begin{column}{6cm}
|
|
\begin{verbatim}
|
|
class PositDefMatrix : public Matrix
|
|
{
|
|
public:
|
|
PositDefMatrix(int n, int p,
|
|
double[] e);
|
|
Matrix cholesky();
|
|
};
|
|
\end{verbatim}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{scriptsize}
|
|
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item \texttt{PositDefMatrix} is a \alert{subclass} (or \alert{derived class}) of \texttt{Matrix}
|
|
\item Conversely \texttt{Matrix} is the \alert{superclass} of \texttt{PositDefMatrix}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Inheritance (2/2)}
|
|
\begin{itemize}
|
|
\item \texttt{PositDefMatrix} inherits \texttt{width}, \texttt{height}, \texttt{elements} and \texttt{det} from \texttt{Matrix}
|
|
\item Method \texttt{cholesky} can be called on an instance of \texttt{PositDefMatrix}, but not of \texttt{Matrix}
|
|
\item The keyword \texttt{protected} means: public for subclasses, but private for other classes
|
|
\item \alert{Type casts} are legal when going upward in the derivation tree:
|
|
\begin{itemize}
|
|
\item a pointer to \texttt{PositDefMatrix} can be safely cast to a \texttt{Matrix*}
|
|
\item the converse is faulty and leads to unpredictable results
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Constructors and destructors (bis)}
|
|
\begin{block}{C++ code snippet}
|
|
\begin{scriptsize}
|
|
\begin{verbatim}
|
|
Matrix::Matrix(int n, int p, double[] e) : height(n), width(p)
|
|
{
|
|
elements = new double[n*p];
|
|
memcpy(elements, e, n*p*sizeof(double));
|
|
}
|
|
|
|
Matrix::~Matrix()
|
|
{
|
|
delete[] elements;
|
|
}
|
|
|
|
PositDefMatrix::PositDefMatrix(int n, int p, double[] e) :
|
|
Matrix(n, p, e)
|
|
{
|
|
// Check that matrix is really positive definite
|
|
}
|
|
\end{verbatim}
|
|
\end{scriptsize}
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Constructor of \texttt{PositDefMatrix} calls constructor of \texttt{Matrix}
|
|
\item Note the abbreviated syntax with colon
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Possible derivation tree for real matrices}
|
|
\framesubtitle{Arrow means \textit{...is a subclass of...}}
|
|
\begin{center}
|
|
\includegraphics[width=10cm]{matrices.png}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Polymorphism (1/3)}
|
|
\begin{itemize}
|
|
\item In previous example, determinant computation method uses the same algorithm for both classes
|
|
\item But for positive definite matrices, a faster algorithm exists (using the cholesky)
|
|
\item \alert{Polymorphism} offers an elegant solution:
|
|
\begin{itemize}
|
|
\item declare \texttt{det} as a \alert{virtual method} in class \texttt{Matrix}
|
|
\item \alert{override} it in \texttt{PositDefMatrix}, and provide the corresponding implementation
|
|
\end{itemize}
|
|
\item When method \texttt{det} will be invoked, the correct implementation will be selected, depending on the type of the instance (this is done through a runtime type test)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Polymorphism (2/3)}
|
|
|
|
\begin{block}{Class headers}
|
|
\begin{scriptsize}
|
|
\begin{columns}[t]
|
|
\begin{column}{4.8cm}
|
|
\begin{verbatim}
|
|
class Matrix
|
|
{
|
|
protected:
|
|
int height, width;
|
|
double[] elements;
|
|
public:
|
|
Matrix(int n, int p,
|
|
double[] e);
|
|
virtual ~Matrix();
|
|
virtual double det();
|
|
bool is_invertible();
|
|
};
|
|
\end{verbatim}
|
|
\end{column}
|
|
\begin{column}{6cm}
|
|
\begin{verbatim}
|
|
class PositDefMatrix : public Matrix
|
|
{
|
|
public:
|
|
PositDefMatrix(int n, int p,
|
|
double[] e);
|
|
Matrix cholesky();
|
|
virtual double det();
|
|
};
|
|
\end{verbatim}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{scriptsize}
|
|
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Note the \texttt{virtual} keyword
|
|
\item A method has been added to determine if matrix is invertible
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Polymorphism (3/3)}
|
|
\begin{block}{C++ code snippet}
|
|
\begin{scriptsize}
|
|
\begin{verbatim}
|
|
bool Matrix::is_invertible()
|
|
{
|
|
return(det() != 0);
|
|
}
|
|
|
|
double PositDefMatrix::det()
|
|
{
|
|
// Square product of diagonal terms of cholesky decomposition
|
|
}
|
|
\end{verbatim}
|
|
\end{scriptsize}
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item A call to \texttt{is\_invertible} on a instance of \texttt{Matrix} will use the generic determinant computation
|
|
\item The same call on an instance of \texttt{PositDefMatrix} will call the specialized determinant computation
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Abstract classes}
|
|
\begin{itemize}
|
|
\item It is possible to create classes which don't provide an implementation for some virtual methods
|
|
\item Syntax in the header: \\
|
|
\texttt{virtual int method\_name() = 0;}
|
|
\item As a consequence, such classes can never be instantiated
|
|
\item Generally used as the root of a derivation tree, when classes of the tree share behaviours but not implementations
|
|
\item Such classes are called \alert{abstract classes}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{Some programming rules (1/2)}
|
|
\begin{itemize}
|
|
\item Don't repeat yourself (DRY): if several functions contain similar portions of code, \alert{factorize} that code into a new function
|
|
\begin{itemize}
|
|
\item makes code shorter
|
|
\item reduces the risk of introducing inconsistencies
|
|
\item makes easier the propagation of enhancements and bug corrections
|
|
\end{itemize}
|
|
\item Make short functions
|
|
\begin{itemize}
|
|
\item often difficult to grasp what a long function does
|
|
\item structuring the code by dividing it into short functions makes the logical structure more apparent
|
|
\item enhances code readability and maintainability
|
|
\end{itemize}
|
|
\item Use explicit variable names (except for loop indexes)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Some programming rules (2/2)}
|
|
\begin{itemize}
|
|
\item Global variables are evil
|
|
\begin{itemize}
|
|
\item a global variable can be modified from anywhere in the code (nonlocality problem)
|
|
\item creates a potentially unlimited number of dependencies between all portions of the code
|
|
\item makes bugs difficult to localize (any part of the code could have created the trouble)
|
|
\item to summarize, goes against the principle of modularity
|
|
\item in addition, global variables are not thread safe (unless used with locks/mutexes)
|
|
\end{itemize}
|
|
\item Document your code when it doesn't speak by itself
|
|
\begin{itemize}
|
|
\item Dynare preprocessor code is documented using Doxygen
|
|
\item done through special comments beginning with an exclamation mark
|
|
\item run \texttt{doxygen} from the source directory to create a bunch of HTML files documenting the code
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Parsing}
|
|
|
|
\begin{frame}
|
|
\frametitle{Parsing overview}
|
|
\begin{itemize}
|
|
\item Parsing is the action of transforming an input text (a \texttt{mod} file in our case) into a data structure suitable for computation
|
|
\item The parser consists of three components:
|
|
\begin{itemize}
|
|
\item the \alert{lexical analyzer}, which recognizes the ``words'' of the \texttt{mod} file (analog to the \textit{vocabulary} of a language)
|
|
\item the \alert{syntax analyzer}, which recognizes the ``sentences'' of the \texttt{mod} file (analog to the \textit{grammar} of a language)
|
|
\item the \alert{parsing driver}, which coordinates the whole process and constructs the data structure using the results of the lexical and syntax analyses
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Lexical analysis}
|
|
\begin{itemize}
|
|
\item The lexical analyzer recognizes the ``words'' (or \alert{lexemes}) of the language
|
|
\item Lexical analyzer is described in \texttt{DynareFlex.ll}. This file is transformed into C++ source code by the program \texttt{flex}
|
|
\item This file gives the list of the known lexemes (described by regular expressions), and gives the associated \alert{token} for each of them
|
|
\item For punctuation (semicolon, parentheses, ...), operators (+, -, ...) or fixed keywords (\textit{e.g.} \texttt{model}, \texttt{varexo}, ...), the token is simply an integer uniquely identifying the lexeme
|
|
\item For variable names or numbers, the token also contains the associated string for further processing
|
|
%\item \textit{Note:} the list of tokens can be found at the beginning of \texttt{DynareBison.yy}
|
|
\item When invoked, the lexical analyzer reads the next characters of the input, tries to recognize a lexeme, and either produces an error or returns the associated token
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Lexical analysis}
|
|
\framesubtitle{An example}
|
|
\begin{itemize}
|
|
\item Suppose the \texttt{mod} file contains the following:
|
|
\begin{verbatim}
|
|
model;
|
|
x = log(3.5);
|
|
end;
|
|
\end{verbatim}
|
|
\item Before lexical analysis, it is only a sequence of characters
|
|
\item The lexical analysis produces the following stream of tokens:
|
|
|
|
\begin{footnotesize}
|
|
\begin{verbatim}
|
|
MODEL
|
|
SEMICOLON
|
|
NAME "x"
|
|
EQUAL
|
|
LOG
|
|
LEFT_PARENTHESIS
|
|
FLOAT_NUMBER "3.5"
|
|
RIGHT_PARENTHESIS
|
|
SEMICOLON
|
|
END
|
|
SEMICOLON
|
|
\end{verbatim}
|
|
\end{footnotesize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Syntax analysis}
|
|
Using the list of tokens produced by lexical analysis, the syntax analyzer determines which ``sentences'' are valid in the language, according to a \alert{grammar} composed of \alert{rules}.
|
|
\begin{block}{A grammar for lists of additive and multiplicative expressions}
|
|
\begin{footnotesize}
|
|
\begin{verbatim}
|
|
%start expression_list;
|
|
|
|
expression_list := expression SEMICOLON
|
|
| expression_list expression SEMICOLON;
|
|
|
|
expression := expression PLUS expression
|
|
| expression TIMES expression
|
|
| LEFT_PAREN expression RIGHT_PAREN
|
|
| INT_NUMBER;
|
|
\end{verbatim}
|
|
\end{footnotesize}
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item \texttt{(1+3)*2; 4+5;} will pass the syntax analysis without error
|
|
\item \texttt{1++2;} will fail the syntax analysis, even though it has passed the lexical analysis
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Syntax analysis}
|
|
\framesubtitle{In Dynare}
|
|
\begin{itemize}
|
|
\item The \texttt{mod} file grammar is described in \texttt{DynareBison.yy}
|
|
\item The grammar is transformed into C++ source code by the program \texttt{bison}
|
|
\item The grammar tells a story which looks like:
|
|
\begin{itemize}
|
|
\item A \texttt{mod} file is a list of statements
|
|
\item A statement can be a \texttt{var} statement, a \texttt{varexo} statement, a \texttt{model} block, an \texttt{initval} block, ...
|
|
\item A \texttt{var} statement begins with the token \texttt{VAR}, then a list of \texttt{NAME}s, then a semicolon
|
|
\item A \texttt{model} block begins with the token \texttt{MODEL}, then a semicolon, then a list of equations separated by semicolons, then an \texttt{END} token
|
|
\item An equation can be either an expression, or an expression followed by an \texttt{EQUAL} token and another expression
|
|
\item An expression can be a \texttt{NAME}, or a \texttt{FLOAT\_NUMBER}, or an expression followed by a \texttt{PLUS} and another expression, ...
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{Semantic actions}
|
|
\begin{itemize}
|
|
\item So far we have only described how to accept valid \texttt{mod} files and to reject others
|
|
\item But validating is not enough: one need to do something about what has been parsed
|
|
\item Each rule of the grammar can have a \alert{semantic action} associated to it: C/C++ code enclosed in curly braces
|
|
\item Each rule can return a semantic value (referenced to by \texttt{\$\$} in the action)
|
|
\item In the action, it is possible to refer to semantic values returned by components of the rule (using \texttt{\$1}, \texttt{\$2}, ...)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Semantic actions}
|
|
\framesubtitle{An example}
|
|
\begin{block}{A simple calculator which prints its results}
|
|
\begin{footnotesize}
|
|
\begin{verbatim}
|
|
%start expression_list
|
|
%type <int> expression
|
|
|
|
expression_list := expression SEMICOLON
|
|
{ cout << $1; }
|
|
| expression_list expression SEMICOLON
|
|
{ cout << $2; };
|
|
|
|
expression := expression PLUS expression
|
|
{ $$ = $1 + $3; }
|
|
| expression TIMES expression
|
|
{ $$ = $1 * $3; }
|
|
| LEFT_PAREN expression RIGHT_PAREN
|
|
{ $$ = $2; }
|
|
| INT_NUMBER
|
|
{ $$ = $1; };
|
|
\end{verbatim}
|
|
\end{footnotesize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Parsing driver}
|
|
|
|
The class \texttt{ParsingDriver} has the following roles:
|
|
\begin{itemize}
|
|
\item Given the \texttt{mod} filename, it opens the file and launches the lexical and syntaxic analyzers on it
|
|
\item It implements most of the semantic actions of the grammar
|
|
\item By doing so, it creates an object of type \texttt{ModFile}, which is the data structure representing the \texttt{mod} file
|
|
\item Or, if there is a parsing error (unknown keyword, undeclared symbol, syntax error), it displays the line and column numbers where the error occurred, and exits
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Data structure representing a \texttt{mod} file}
|
|
|
|
\begin{frame}
|
|
\frametitle{The \texttt{ModFile} class}
|
|
\begin{itemize}
|
|
\item This class is the internal data structure used to store all the informations contained in a \texttt{mod} file
|
|
\item One instance of the class represents one \texttt{mod} file
|
|
\item The class contains the following elements (as class members):
|
|
\begin{itemize}
|
|
\item a symbol table
|
|
\item a numerical constants table
|
|
\item two trees of expressions: one for the model, and one for the expressions outside the model
|
|
\item the list of the statements (parameter initializations, shocks block, \texttt{check}, \texttt{steady}, \texttt{simul}, ...)
|
|
\item an evaluation context
|
|
\end{itemize}
|
|
\item An instance of \texttt{ModFile} is the output of the parsing process (return value of \texttt{ParsingDriver::parse()})
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{The symbol table (1/3)}
|
|
\begin{itemize}
|
|
\item A \alert{symbol} is simply the name of a variable, of a parameter or of a function unknown to the preprocessor: actually everything that is not recognized as a Dynare keyword
|
|
\item The \alert{symbol table} is a simple structure used to maintain the list of the symbols used in the \texttt{mod} file
|
|
\item For each symbol, stores:
|
|
\begin{itemize}
|
|
\item its name (a string)
|
|
\item its type (an integer)
|
|
\item a unique integer identifier (unique for a given type, but not across types)
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{The symbol table (2/3)}
|
|
Existing types of symbols:
|
|
\begin{itemize}
|
|
\item Endogenous variables
|
|
\item Exogenous variables
|
|
\item Exogenous deterministic variables
|
|
\item Parameters
|
|
\item Local variables inside model: declared with a pound sign (\#) construction
|
|
\item Local variables outside model: no declaration needed, not interpreted by the preprocessor (\textit{e.g.} Matlab loop indexes)
|
|
\item Names of functions unknown to the preprocessor: no declaration needed, not interpreted by the preprocessor, only allowed outside model (until we create an interface for providing custom functions with their derivatives)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{The symbol table (2/3)}
|
|
\begin{itemize}
|
|
\item Symbol table filled in:
|
|
\begin{itemize}
|
|
\item using the \texttt{var}, \texttt{varexo}, \texttt{varexo\_det}, \texttt{parameter} declarations
|
|
\item using pound sign (\#) constructions in the model block
|
|
\item on the fly during parsing: local variables outside models or unknown functions when an undeclared symbol is encountered
|
|
\end{itemize}
|
|
\item Roles of the symbol table:
|
|
\begin{itemize}
|
|
\item permits parcimonious and more efficient representation of expressions (no need to duplicate or compare strings, only handle a pair of integers)
|
|
\item ensures that a given symbol is used with only one type
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Expression trees (1/2)}
|
|
\begin{itemize}
|
|
\item The data structure used to store expressions is essentially a \alert{tree}
|
|
\item Graphically, the tree representation of $(1+z)*\log(y)$ is:
|
|
\begin{center}
|
|
\includegraphics[width=4cm]{expr.png}
|
|
\end{center}
|
|
\item No need to store parentheses
|
|
\item Each circle represents a \alert{node}
|
|
\item A node has at most one parent and at most two children
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Expression trees (2/2)}
|
|
\begin{itemize}
|
|
\item In Dynare preprocessor, a tree node is a represented by an instance of the abstract class \texttt{ExprNode}
|
|
\item This class has 5 sub-classes, corresponding to the 5 types of nodes:
|
|
\begin{itemize}
|
|
\item \texttt{NumConstNode} for constant nodes: contains the identifier of the numerical constants it represents
|
|
\item \texttt{VariableNode} for variable/parameters nodes: contains the identifier of the variable or parameter it represents
|
|
\item \texttt{UnaryOpNode} for unary operators (\textit{e.g.} unary minus, $\log$, $\sin$): contains an integer representing the operator, and a pointer to its child
|
|
\item \texttt{BinaryOpNode} for binary operators (\textit{e.g.} $+$, $*$, pow): contains an integer representing the operator, and pointers to its two children
|
|
\item \texttt{UnknownFunctionNode} for functions unknown to the parser (\textit{e.g.} user defined functions): contains the identifier of the function name, and a vector containing an arbitrary number of children (the function arguments)
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Classes \texttt{DataTree} and \texttt{ModelTree}}
|
|
\begin{itemize}
|
|
\item Class \texttt{DataTree} is a container for storing a set of expression trees
|
|
\item Class \texttt{ModelTree} is a sub-class of \texttt{DataTree}, specialized for storing a set of model equations (among other things, contains symbolic derivation algorithm)
|
|
\item Class \texttt{ModFile} contains:
|
|
\begin{itemize}
|
|
\item one instance of \texttt{ModelTree} for storing the equations of model block
|
|
\item one instance of \texttt{DataTree} for storing all expressions outside model block
|
|
\end{itemize}
|
|
\item Expression storage is optimized through three mechanisms:
|
|
\begin{itemize}
|
|
\item pre-computing of numerical constants
|
|
\item symbolic simplification rules
|
|
\item sub-expression sharing
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Constructing expression trees}
|
|
\begin{itemize}
|
|
\item Class \texttt{DataTree} contains a set of methods for constructing expression trees
|
|
\item Construction is done bottom-up, node by node:
|
|
\begin{itemize}
|
|
\item one method for adding a constant node (\texttt{AddPossiblyNegativeConstant(double)})
|
|
\item one method for a log node (\texttt{AddLog(arg)})
|
|
\item one method for a plus node (\texttt{AddPlus(arg1, arg2)})
|
|
\end{itemize}
|
|
\item These methods take pointers to \texttt{ExprNode}, allocate the memory for the node, construct it, and return its pointer
|
|
\item These methods are called:
|
|
\begin{itemize}
|
|
\item from \texttt{ParsingDriver} in the semantic actions associated to the parsing of expressions
|
|
\item during symbolic derivation, to create derivatives expressions
|
|
\end{itemize}
|
|
\item Note that \texttt{NodeID} is an alias (typedef) for \texttt{ExprNode*}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Reduction of constants and symbolic simplifications}
|
|
\begin{itemize}
|
|
\item The construction methods compute constants whenever it is possible
|
|
\begin{itemize}
|
|
\item Suppose you ask to construct the node $1+1$
|
|
\item The \texttt{AddPlus()} method will return a pointer to a constant node containing 2
|
|
\end{itemize}
|
|
\item The construction methods also apply a set of simplification rules, such as:
|
|
\begin{itemize}
|
|
\item $0+0=0$
|
|
\item $x+0 = x$
|
|
\item $0-x = -x$
|
|
\item $-(-x) = x$
|
|
\item $x*0 = 0$
|
|
\item $x/1 = x$
|
|
\item $x^0 = 1$
|
|
\end{itemize}
|
|
\item When a simplification rule applies, no new node is created
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Sub-expression sharing (1/2)}
|
|
\begin{itemize}
|
|
\item Consider the two following expressions: $(1+z)*\log(y)$ and $2^{(1+z)}$
|
|
\item Expressions share a common sub-expression: $1+z$
|
|
\item The internal representation of these expressions is:
|
|
\begin{center}
|
|
\includegraphics[width=6cm]{expr-sharing.png}
|
|
\end{center}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Sub-expression sharing (2/2)}
|
|
\begin{itemize}
|
|
\item Construction methods implement a simple algorithm which achieves maximal expression sharing
|
|
\item Algorithm uses the fact that each node has a unique memory address (pointer to the corresponding instance of \texttt{ExprNode})
|
|
\item It maintains 5 tables which keep track of the already constructed nodes: one table by type of node (constants, variables, unary ops, binary ops, unknown functions)
|
|
\item Suppose you want to create the node $e_1+e_2$ (where $e_1$ and $e_2$ are sub-expressions):
|
|
\begin{itemize}
|
|
\item the algorithm searches the binary ops table for the tuple equal to (address of $e_1$, address of $e_2$, op code of +) (it is the \alert{search key})
|
|
\item if the tuple is found in the table, the node already exists, and its memory address is returned
|
|
\item otherwise, the node is created, and is added to the table with its search key
|
|
\end{itemize}
|
|
\item Maximum sharing is achieved, because expression trees are constructed bottom-up
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Final remarks about expressions}
|
|
\begin{itemize}
|
|
\item Storage of negative constants
|
|
\begin{itemize}
|
|
\item class \texttt{NumConstNode} only accepts positive constants
|
|
\item a negative constant is stored as a unary minus applied to a positive constant
|
|
\item this is a kind of identification constraint to avoid having two ways of representing negative constants: $(-2)$ and $-(2)$
|
|
\end{itemize}
|
|
\item Widely used constants
|
|
\begin{itemize}
|
|
\item class \texttt{DataTree} has attributes containing pointers to one, zero, and minus one constants
|
|
\item these constants are used in many places (in simplification rules, in derivation algorithm...)
|
|
\item sub-expression sharing algorithm ensures that those constants will never be duplicated
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{List of statements}
|
|
\begin{itemize}
|
|
\item A statement is represented by an instance of a subclass of the abstract class \texttt{Statement}
|
|
\item Three groups of statements:
|
|
\begin{itemize}
|
|
\item initialization statements (parameter initialization with $p = \ldots$, \texttt{initval}, \texttt{histval} or \texttt{endval} block)
|
|
\item shocks blocks
|
|
\item computing tasks (\texttt{check}, \texttt{simul}, ...)
|
|
\end{itemize}
|
|
\item Each type of statement has its own class (\textit{e.g.} \texttt{InitValStatement}, \texttt{SimulStatement}, ...)
|
|
\item The class \texttt{ModFile} stores a list of pointers of type \texttt{Statement*}, corresponding to the statements of the \texttt{mod} file, in their order of declaration
|
|
\item Heavy use of polymorphism in the check pass, computing pass, and when writing outputs: abstract class \texttt{Statement} provides a virtual method for these 3 actions
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Evaluation context}
|
|
\begin{itemize}
|
|
\item The \texttt{ModFile} class contains an \alert{evaluation context}
|
|
\item It is a map associating a numerical value to some symbols
|
|
\item Filled in with \texttt{initval} block, and with parameters initializations
|
|
\item Used during equation normalization (in the block decomposition), for finding non-zero entries in the jacobian
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Check pass}
|
|
|
|
\begin{frame}
|
|
\frametitle{Error checking during parsing}
|
|
\begin{itemize}
|
|
\item Some errors in the \texttt{mod} file can be detected during the parsing:
|
|
\begin{itemize}
|
|
\item syntax errors
|
|
\item use of undeclared symbol in model block, initval block...
|
|
\item use of a symbol incompatible with its type (\textit{e.g.} parameter in initval, local variable used both in model and outside model)
|
|
\item multiple shocks declaration for the same variable
|
|
\end{itemize}
|
|
\item But some other checks can only be done when parsing is completed
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Check pass}
|
|
\begin{itemize}
|
|
\item The check pass is implemented through method \texttt{ModFile::checkPass()}
|
|
\item Does the following checks:
|
|
\begin{itemize}
|
|
\item check there is at least one equation in the model (except if doing a standalone BVAR estimation)
|
|
\item check there is not both a \texttt{simul} and a \texttt{stoch\_simul} (or another command triggering local approximation)
|
|
\end{itemize}
|
|
\item Other checks could be added in the future, for example:
|
|
\begin{itemize}
|
|
\item check that every endogenous variable is used at least once in current period
|
|
\item check there is a single \texttt{initval} (or \texttt{histval}, \texttt{endval}) block
|
|
\item check that \texttt{varobs} is used if there is an estimation
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Computing pass}
|
|
|
|
\begin{frame}
|
|
\frametitle{Overview of the computing pass}
|
|
\begin{itemize}
|
|
\item Computing pass implemented in \texttt{ModFile::computingPass()}
|
|
\item Begins with a determination of which derivatives to compute
|
|
\item Then, calls \texttt{ModelTree::computingPass()}, which computes:
|
|
\begin{itemize}
|
|
\item leag/lag variable incidence matrix
|
|
\item symbolic derivatives
|
|
\item equation normalization + block decomposition (only in \texttt{sparse\_dll} mode)
|
|
\item temporary terms
|
|
\item symbolic gaussian elimination (only in \texttt{sparse\_dll} mode) \textit{(actually this is done in the output writing pass, but should be moved to the computing pass)}
|
|
\end{itemize}
|
|
\item Finally, calls \texttt{Statement::computingPass()} on all statements
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{The variable table}
|
|
\begin{itemize}
|
|
\item In the context of class \texttt{ModelTree}, a \alert{variable} is a pair (symbol, lead/lag)
|
|
\item The symbol must correspond to an endogenous or exogenous variable (in the sense of the model)
|
|
\item The class \texttt{VariableTable} keeps track of those pairs
|
|
\item An instance of \texttt{ModelTree} contains an instance of \texttt{VariableTable}
|
|
\item Each pair (\texttt{symbol\_id}, lead/lag) is given a unique \texttt{variable\_id}
|
|
\item After the computing pass, the class \texttt{VariableTable} writes the leag/lag incidence matrix:
|
|
\begin{itemize}
|
|
\item endogenous symbols in row
|
|
\item leads/lags in column
|
|
\item elements of the matrix are either 0 or correspond to a variable ID, depending on whether the pair (symbol, lead/lag) is used or not in the model
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Static versus dynamic model}
|
|
\begin{itemize}
|
|
\item The static model is simply the (dynamic) model from which the leads/lags have been omitted
|
|
\item Static model used to characterize the steady state
|
|
\item The jacobian of the static model is used in the (Matlab) solver for determining the steady state
|
|
\item No need to derive static and dynamic models independently: \\
|
|
static derivatives can be easily deduced from dynamic derivatives
|
|
\end{itemize}
|
|
\begin{block}{Example}
|
|
\begin{itemize}
|
|
\item suppose dynamic model is $2x \cdot x_{-1} = 0$
|
|
\item static model is $2x^2 = 0$, whose derivative w.r. to $x$ is $4x$
|
|
\item dynamic derivative w.r. to $x$ is $2x_{-1}$, and w.r. to $x_{-1}$ is $2x$
|
|
\item removing leads/lags from dynamic derivatives and summing over the two partial derivatives w.r. to $x$ and $x_{-1}$ gives $4x$
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Which derivatives to compute ?}
|
|
\begin{itemize}
|
|
\item In deterministic mode:
|
|
\begin{itemize}
|
|
\item static jacobian (w.r. to endogenous variables only)
|
|
\item dynamic jacobian (w.r. to endogenous variables only)
|
|
\end{itemize}
|
|
\item In stochastic mode:
|
|
\begin{itemize}
|
|
\item static jacobian (w.r. to endogenous variables only)
|
|
\item dynamic jacobian (w.r. to all variables)
|
|
\item possibly dynamic hessian (if \texttt{order} option $\geq 2$)
|
|
\item possibly dynamic 3rd derivatives (if \texttt{order} option $\geq 3$)
|
|
\end{itemize}
|
|
\item For ramsey policy: the same as above, but with one further order of derivation than declared by the user with \texttt{order} option (the derivation order is determined in the check pass, see \texttt{RamseyPolicyStatement::checkPass()})
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Derivation algorithm (1/2)}
|
|
\begin{itemize}
|
|
\item Derivation of the model implemented in \texttt{ModelTree::derive()}
|
|
\item Simply calls \texttt{ExprNode::getDerivative(varID)} on each equation node
|
|
\item Use of polymorphism:
|
|
\begin{itemize}
|
|
\item for a constant or variable node, derivative is straightforward (0 or 1)
|
|
\item for a unary or binary op node, recursively calls method \texttt{getDerivative()} on children to construct derivative of parent, using usual derivation rules, such as:
|
|
\begin{itemize}
|
|
\item $(log(e))' = \frac{e'}{e}$
|
|
\item $(e_1 + e_2)' = e'_1 + e'_2$
|
|
\item $(e_1 \cdot e_2)' = e'_1\cdot e_2 + e_1\cdot e'_2$
|
|
\item $\ldots$
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Derivation algorithm (2/2)}
|
|
\framesubtitle{Optimizations}
|
|
\begin{itemize}
|
|
\item Caching of derivation results
|
|
\begin{itemize}
|
|
\item method \texttt{ExprNode::getDerivative(varID)} memorizes its result in a member attribute the first time it is called
|
|
\item so that the second time it is called (with the same argument), simply returns the cached value without recomputation
|
|
\item caching is useful because of sub-expression sharing
|
|
\end{itemize}
|
|
\pause
|
|
\item Symbolic \textit{a priori}
|
|
\begin{itemize}
|
|
\item consider the expression $x+y^2$
|
|
\item without any computation, you know its derivative w.r. to $z$ is zero
|
|
\item each node stores in an attribute the set of variables which appear in the expression it represents ($\{x,y\}$ in the example)
|
|
\item that set is computed in the constructor (straigthforwardly for a variable or a constant, recursively for other nodes, using the sets of the children)
|
|
\item when \texttt{getDerivative(varID)} is called, immediately returns zero if \texttt{varID} is not in that set
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{Temporary terms (1/2)}
|
|
\begin{itemize}
|
|
\item When the preprocessor writes equations and derivatives in its outputs, it takes advantage of sub-expression sharing
|
|
\item In Matlab static and dynamic output files, equations are preceded by a list of \alert{temporary terms}
|
|
\item Those terms are temporary variables containing expressions shared by several equations or derivatives
|
|
\item Doing so greatly enhances the computing speed of model residual, jacobian or hessian
|
|
\end{itemize}
|
|
\begin{block}{Example}
|
|
\begin{columns}[t]
|
|
\begin{column}{6cm}
|
|
The equations:
|
|
\begin{verbatim}
|
|
residual(0)=x+y^2-z^3;
|
|
residual(1)=3*(x+y^2)+1;
|
|
\end{verbatim}
|
|
\end{column}
|
|
\begin{column}{4.8cm}
|
|
Can be optimized in:
|
|
\begin{verbatim}
|
|
T01=x+y^2;
|
|
residual(0)=T01-z^3;
|
|
residual(1)=3*T01+1;
|
|
\end{verbatim}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Temporary terms (2/2)}
|
|
\begin{itemize}
|
|
\item Expression storage in the preprocessor implements maximal sharing...
|
|
\item ...but it is not optimal for the Matlab output files, because creating a temporary variable also has a cost (in terms of CPU and of memory)
|
|
\item Computation of temporary terms implements a trade-off between:
|
|
\begin{itemize}
|
|
\item cost of duplicating sub-expressions
|
|
\item cost of creating new variables
|
|
\end{itemize}
|
|
\item Algorithm uses a recursive cost calculation, which marks some nodes as being ``temporary''
|
|
\item \textit{Problem}: redundant with optimizations done by the C/C++ compiler (when Dynare is in DLL mode) $\Rightarrow$ compilation very slow on big models
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{The special case of Ramsey policy}
|
|
\begin{itemize}
|
|
\item For most statements, the method \texttt{computingPass()} is a no-op...
|
|
\item ...except for \texttt{planner\_objective} statement, which serves to declare planner objective when doing optimal policy under commitment
|
|
\item Class \texttt{PlannerObjectiveStatement} contains an instance of \texttt{ModelTree}: used to store the objective (only one equation in the tree)
|
|
\item During the computing pass, triggers the computation of the first and second order (static) derivatives of the objective
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Writing outputs}
|
|
|
|
\begin{frame}
|
|
\frametitle{Output overview}
|
|
\begin{itemize}
|
|
\item Implemented in \texttt{ModFile::writeOutputFiles()}
|
|
\item If \texttt{mod} file is \texttt{model.mod}, all created filenames will begin with \texttt{model}
|
|
\item Main output file is \texttt{model.m}, containing:
|
|
\begin{itemize}
|
|
\item general initialization commands
|
|
\item symbol table output (from \texttt{SymbolTable::writeOutput()})
|
|
\item lead/lag incidence matrix (from \texttt{ModelTree::writeOutput()})
|
|
\item call to Matlab functions corresponding to the statements of the \texttt{mod} file (written by calling \texttt{Statement::writeOutput()} on all statements through polymorphism)
|
|
\end{itemize}
|
|
\item Subsidiary output files:
|
|
\begin{itemize}
|
|
\item one for the static model
|
|
\item one for the dynamic model
|
|
\item and one for the planner objective (if relevant)
|
|
\item written through \texttt{ModelTree} methods: \texttt{writeStaticFile()} and \texttt{writeDynamicFile()}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Model output files}
|
|
Three possibles modes for \texttt{ModelTree} (see \texttt{mode} attribute):
|
|
\begin{itemize}
|
|
\item Standard mode: static and dynamic files in Matlab
|
|
\item DLL mode:
|
|
\begin{itemize}
|
|
\item static and dynamic files in C++ source code (with corresponding headers)
|
|
\item compiled through \texttt{mex} to allow execution from within Matlab
|
|
\end{itemize}
|
|
\item Sparse DLL mode:
|
|
\begin{itemize}
|
|
\item static file in Matlab
|
|
\item two possibilities for dynamic file:
|
|
\begin{itemize}
|
|
\item by default, a C++ source file (with header) and a binary file, to be read from the C++ code
|
|
\item or, with \texttt{no\_compiler} option, a binary file in custom format, executed from Matlab through \texttt{simulate} DLL
|
|
\item the second option serves to bypass compilation of C++ file which can be very slow
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Conclusion}
|
|
|
|
\begin{frame}
|
|
\frametitle{Future work (1/2)}
|
|
\framesubtitle{Enhancements, optimizations}
|
|
\begin{itemize}
|
|
\item Refactor and reorganize some portions of the code
|
|
\item Create a testsuite (with unitary tests)
|
|
\item Separate computation of temporary terms between static and dynamic outputs
|
|
\item Enhance sub-expression sharing algorithm (using associativity, commutativity and factorization rules)
|
|
\item Add many checks on the structure of the \texttt{mod} file
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Future work (2/2)}
|
|
\framesubtitle{Features}
|
|
\begin{itemize}
|
|
\item Add precompiler macros (\#include, \#define, \#if)
|
|
\item Add handling for several (sub-)models
|
|
\item Add indexed variables and control statements (if, loops) both in models and command language
|
|
\item Add sum, diff, prod operators
|
|
\item For unknown functions in the model: let user provide a derivative, or trigger numerical derivation
|
|
\item Generalize binary code output
|
|
\item Generalize block decomposition ?
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\end{document}
|