The Python SFC Model Workflow

The way in the which the sfc_models package is typically used is distinctive. The objective is to focus the user’s attention upon the linkages between sectors of the economy, and not on the drudgery of national accounting. It is a preliminary computer-aided design (CAD) package for economics.

[This is a first draft of section taken from my next book in progress - Introduction to SFC Models Using Python.]

(As an editorial note, this section will follow another that offers an initial description of the sfc_models package. In case the reader is unfamiliar with it, this is an open source package that is currently under development that allows the user to build and solve stock-flow consistent (SFC) models in Python. I have previously generated examples using this framework; and will continue to refer to it as I finish the book. As for my latest book -- Abolish Money (From Economics)! -- I am currently finishing off the paperback edition, and will need to see a proof copy before it is put up for sale.)

The steps involved in using the package are as follows. This section only offers an overview of these steps; the rest of the book fills out the detail.

1. The Python code imports the sfc_models package.
2. The user then creates objects that represent the economic sectors. (There is an explanation of what is meant by objects below.) Behavioural parameters are specified, and the linkages between the sectors.
3. Once the objects are created, the model building operation of the sfc_models framework is invoked.
4. The framework generates the equations that specify the model based on the sector object properties. These equations are specified within a text block that is output to log files that can be examined by the user.
5. The framework then invokes an equation solver that takes as an input the equations in text form. It then generates time series outputs, assuming that it can find a solution to the system of equations. (If the user’s specifications of the economic sectors are missing linkages or are internally inconsistent, there may not be a solution. Alternatively, the user may have specified behavioural relationships that are beyond the capacity of the solver.)
6. The framework then saves the time series as a text-delimited file (“csv file”), as well as Python objects that can be further analysed using other Python code. For example, the time series plots in this report in other posts on this web site were created using the matplotlib Python package.

At the time of writing, this workflow relies upon the user running Python code. This need not be greatly complex; the reader is free to invoke example code that is provided to generate the output that matches what is displayed in this report. Once the sfc_models code is sufficiently advanced, it should be possible for the user to specify the configuration of economic sectors within the model by using a graphical user interface (GUI). In other words, it would be possible to build a model with “drag and drop” operations within a window. This would allow students to examine a variety of economic models and see how they behave as conditions change. Such an approach would allow a more “hands on” approach to learning, and not rely upon following others’ interpretations of how the economy works.

Returning to the workflow above, steps 1-3 are implemented by the user, and the framework generally finishes off the operations. That said, the user has control over the remaining steps if desired.

• The user can take the generated equations, and solve them using other techniques. Since the equations created are visible, the models generated by the framework are not opaque black boxes.
• The user can generate model equations by hand, and then input the equations into the sfc_models solver.
• The user is free to import the time series data into other software for further processing. For example, loading the data into a spreadsheet is probably the easiest way to look at the behaviour of all the time series within the model solution.

The description above refers to the creation of objects. This is not a case of being vague; rather it is using software engineering jargon. In this case, the objects are components of object-oriented programming, which may not be familiar to readers who have not studied software engineering, but were instead taught how to program by non-specialists, who typically take a procedural programming approach.

Under the object-oriented approach, code is created in a modular form, with objects that comprise both the functions that determine behaviour, as well as the data structures associated with those functions. In order to reduce the problems caused by inter-connected code, the objects are designed to be distinct, or inherit properties from parent objects in a hierarchical fashion.

In this case, this means that the code that defines how a sector behaves is independent of the rest of the model. For example, we can modify the behavioural functions defining household behaviour without worrying about the implementation of the business sector. This allows us to make changes without having to worry about unexpected code interactions. If a sector’s behaviour depends upon information from another sector, the user just needs to look at the external interface of that sector, without needing to delve into the implementation details of that other sector.

<Another section in the book> discusses the differences between object-oriented programming and procedural programming.

The advantage of using the sfc_models framework is the ease of experimentation. The traditional way to develop SFC models is determine the equations to be solved by hand, and then using software to generate the solution. The difficulty with this manual approach is that it is not obvious how to modify equations if you want to make changes to the economic model. Furthermore, the solution is prone to errors, as you need to transcribe dozens of equations comprised of variables with similar names to a software package. Conversely, building an economic model using sfc_models only requires a handful of lines of user code, and the structure of the code gives a good idea of the structure of the model, even to a non-specialist. Furthermore, the user can see the generated equations, but never needs to work with them manually.

(c) Brian Romanchuk 2017