The text Monetary Economics: An Integrated Approach to Credit, Money, Income, Production and Wealth, by Wynne Godley and Marc Lavoie is cited heavily within the sfc_models framework. This text is a standard text for SFC modelling, and has already been the object of extensive modelling. The fact that the models are well known is extremely useful from the point of view of development. These existing models were used to calibrate the sfc_models code.
(This article is an unedited draft of a section from my upcoming book "Introduction to SFC Models with Python.")
Users who wish to implement directly the models from Monetary Economics can do so by using the code in the sfc_models.gl_book sub-package. There are modules within the gl_book package that correspond to the chapters of the book. (In some cases, there are multiple models within each chapter.) At the time of writing, the coverage of models is quite selective, but more may be added over time. Examples of this direct object creation are given later. However, the user may examine the source code for the chapter modules to see the operations to create the models directly. In particular, if you wish to experiment with the models, it would be best to build the models by copying the source code. The code in the gl_book sub-package is designed to emulate the models in the book exactly, as this is needed for calibration.
This calibration effort may be invisible to most users of the sfc_models package, but it is a key reason why the package should be a stable programming environment. As discussed in <another section of the book>, Python has well-developed unit testing capabilities. Other than some areas of code that inherently cannot be tested – and are explicitly marked as such – the objective is that 100% of the lines of code are exercised in tests. These unit tests call functions and methods, and ensure that the output matches expectations.
Code that is designed to be unit tested needs to be broken into small blocks; spaghetti code has to be avoided. Each of the small components is tested separately, so that changes to one block do not break hundreds of tests because of a desired change of behaviour.
The risk with testing of this nature is that we are focused on testing small parts, and it may be possible that changes will break the code in unexpected ways due to unforeseen interactions. Therefore, we need to augment smaller unit tests with end-to-end tests. These end-to-end tests do large operations, but only examine the final results; implementation details are allowed to remain flexible. For sfc_models, the model outputs from selected models from Monetary Economics were used as end-to-end tests. Since the models were implemented elsewhere already, the target output data (based on fixed inputs) were already available. It was possible to use these target data to ensure that the models generated by sfc_models matched the existing results.
It would have been possible for me to develop the package to generate models that behaved differently. However, such models would be non-standard, and one of the first things users would want is to be able to emulate the models in Monetary Economics. Rather than start from an unorthodox position, I instead decided to be able to emulate the existing structures in Monetary Economics perfectly, and leave the job of creating new types of models as future extensions under the control of users.
One difference between the sfc_models framework and that of Godley and Lavoie is the equation structure. Since the sfc_models equations are generated algorithmically, they needed to be set up in a generic fashion that allows the algorithms to create connections between sectors in a flexible manner. As a result, the initial set of equations generated by sfc_models features many redundant equations (that are pruned by the solver). This destroys some of the mathematical elegance.
A second difference is cosmetic: variables in sfc_models are based on an algorithmic scheme based on long text strings, while Godley and Lavoie use standard variable names from economics, using mathematical notation with subscripts. Therefore, the user needs to “translate” variable names when comparing results.
The final difference is a limitation of the sfc_models framework: there is no mechanism to generate the transaction matrices that are a prominent feature of Monetary Economics. It may be possible to infer such matrices from the economic model structure, but the feasibility of that step has not yet been examined.
(c) Brian Romanchuk 2017
Post a Comment
Note: Posts are manually moderated, with a varying delay. Some disappear.
The comment section here is largely dead. My Substack or Twitter are better places to have a conversation.
Given that this is largely a backup way to reach me, I am going to reject posts that annoy me. Please post lengthy essays elsewhere.