Tuesday, November 25, 2014

Installation: "I should have left the default"

This series of posts began on 18 November

Inforum's The G7 Regression Program page is pretty friendly. And you can download the G7 from there.

So that's where I went, and clicked the shiny button to "Get G7 Here"
That took me to the Software Downloads page
Then I clicked the blue PDG for the "Stable" version

PDG.exe, 26.3 meg
It's taking a few minutes...

The Software Downloads page says you have to "unblock" the file after the download. While waiting, I looked that up.

Delay's Blog says "ZIP files should be "unblocked" before their contents are extracted."

TechNet says "By default, these files are blocked to protect the computer from untrusted files" and wants you to "review the file and its source and verify that it is safe to open."
(I forgot to grab the TechNet link.)

Nobody says how you're supposed to know if something is "safe".

The download took five minutes. I moved the file to a "temp" folder, unblocked it, and ran it.

Yeah, by default the thing will unzip its files to the folder you run it from. I don't want all those files in my "downloads" folder, but the "Temp" folder is fine.

"307 file(s) unzipped successfully."

They ended up in a PDG subfolder in my Temp folder. I'm using Windows Vista, by the way, and hoping to upgrade at Christmas...

I didn't know what to do next. But the Software Downloads page starts by saying: "To install G7 on a machine for the first time, please follow the instructions on the G7 page." So I clicked that, and ended up back at the friendly page. It says:
PDG - This is a self-extracting ZIP file of the G7 program and other Inforum software. After downloading this file, run it by double-clicking on it, or by typing its name at a DOS prompt. Do this in a temporary directory. One of the files that will be extracted is SETUP.EXE. Next, run this setup program, and the InstallShield session will begin. This will load the software into the default location of C:\PDG. See the Readme files that are included in the installation for further instructions.

So far so good. Next, run setup.exe.

A pretty picture of a house comes up in the InstallShield Wizard. After clicking "next" a couple times, a readme file comes up. This is not like something that I might throw together myself. It is all very professional. Trustworthy.

Oh good, Windows Vista is given as an example of the environment you might be using for G7. The first stuff I read on this a few days back said Windows XP or 7 or 8 but didn't mention Vista. So far so good, then.

The readme says you have to add C:\PDG (or, the path to where G7 will be installed) to the Windows PATH variable. I did that right away because I wouldn't remember to do it after the installation is complete. The instructions are right there in the readme, and they are excellent. I didn't have any question in any step of the process. When they tell you to click OK, they also tell you which window you should be in at the moment, and I was in that window every time. I think that's the best computer instructions I ever saw.

Oh, I'm gonna quote this bit for later:
To employ some of the newest features in G7, your system must have an installation of the Microsoft VC++ 2005 Redistributable package. You can find a copy of the VC++ installer under C:\PDG\VC++Installer. Run the installer before attempting to run G7.

Run the installer before attempting to run G7... but after I install G7. Which I didn't get to yet. I'm still reading the readme.


Okay, I'm done with the readme.
There are some questions related to installation. I just accept the defaults, unless I see something odd.

I see something odd. The InstallShield Wizard's Destination Folder window by default will install G7 to the root directory C:\ but that's no good. A program goes in its own directory, so you don't get a jumble of shit in the root. Anyway I already put C:\PDG on the path. That's the one I want.

I clicked Change, a window opened showing I was in the root directory, I clicked the icon to create a new folder, typed PDG, and clicked OK. Done.

Now InstallShield says: Install G7 to C:\PDG. Excellent. I clicked next.


The "Typical" setup type installs everything. That's the default and that's what I want.

Now, click Install...
Start 5:12 AM...
After a moment the activity begins...
Oh, done! at 5:14.
Readme? Yes...
Yeah, this is the same readme file that I read before. I had to do something... Run the installer for VC++

Okay, now I can close the Temp folder and the Temp\PDG folder, and open C:\PDG.

Hm. In my C:\PDG folder there is nothing but a PDG folder, and everything is in there. If this is a problem I will revise the path variable later.

VC++ Installer is there. It installs quickly but then there is a long delay while it says "time remaining 0 seconds"... but the window closed while I was typing this. Okay.

Close the VC++ Installer folder...
Close the Readme window...
Close the Control Panel window where I add PDG to the path...

OKAY. Now I don't know what to do. Run the thing, I guess.

In the GDP folder I double clicked on G7.EXE and two windows opened. It's a demo. The one window is the demo and the other is the script for the demo, it looks like. But nothing is happening. In the script I see things like "When you are done reading, Click OK" but they don't show up in the demo.

Maybe I have to *run* it?

I click the triangle symbol in the demo window menu, the right-pointing triangle. The thing runs, I get a paragraph of text, and a "When you are done reading, Click OK" message.


Monday, November 24, 2014

"The first section of chapter 1 does not require the use of computers"

Today's title is a quote from The Craft of Economic Modeling, Part 1 (PDF), by Clopper Almon. I take the quote to mean that I don't have to begin by getting into the modeling software they call G7. I take it to mean I can start with a spreadsheet. Not pencil and paper and slide rule.

Page six of The Craft presents Table 1.1, a table of data to use for the first simulation. For the first model, I mean. Ten columns of numbers. Most of them are incomplete. The first column (which is complete) contains the numbers 1 thru 24, in order. It is labeled "Line" (meaning 'row number') but I take it to represent years 1 thru 24 of the simulation I'm going to create.

Three other columns are also complete, each with 24 values. Here we have numbers that are predetermined and invariant, regardless of how the simulation works out. These complete columns hold "exogenous" values. Those values don't depend on the outcome of the simulation.

In each of the six remaining columns, only the first few numbers are filled in. These are starter values. A lot of them are used by the calculations of the model -- used by calculations to fill in the blanks where numbers are not given.

The calculations produce "endogenous" values. If things go a little differently in the simulation -- if you change an exogenous value or if you change a calculation, say -- the endogenous numbers will probably all change.

When I put the numbers into a spreadsheet, I switched over to calculations as soon as I could. That way I could compare my calculations to some of the givens, and check my work. In the Zoho spreadsheet, I show the numbers in blue if I used given values, and black if I used calculations. The table of numbers starts just below this graph:

Check my work. I was expecting my graph to come out like the one on page 5 --

But I only got two growth spurts. They got five. I checked my work and didn't see any mistakes. (Oh, there were mistakes. But you look at the graph and see the date when it seems to go crazy, and then you check your calculations on the rows around that date. And you fix 'em before you put it on your blog.) I think I got all the mistakes, but if you find anything fishy, let me know.

I'm assuming the page 5 graph was generated from different data, and that's why the graphs don't match.

If you create the model yourself, do let me know how it comes out.

Note: When you enter the equations it's easy to use the wrong column. It's easy to confuse spreadsheet columns with economic data category columns. For example, the last spreadsheet column used here is column J, which contains economic data column Y, Disposable Income. It's a little messy, keeping it straight. But if you don't do it right you'll know, because your graph won't look right.

// This series of posts began on 18 November 2014.

Sunday, November 23, 2014


To speak of cause and effect in economics, one must have in mind some kind of model.  It may be an entirely subconscious model, or a model spelled out in theory but never quantified or tested, or an explicit, quantified model that has been subjected to careful testing and scrutiny. I need hardly add in which sort I have the greater confidence.

Friday, November 21, 2014

Columns in a spreadsheet go up-and-down, like columns in a building. Rows go across.

Following up on the post of 18 November...

When I picture an economic model, I picture doing it in a spreadsheet. I need a column for "Year", one for "GDP", one for "Debt", one for "Addition to Debt", and stuff like that -- whatever it turns out that the calculation seems to need. And then, make a row for each year of the model's life. I plug in a few numbers on the top row, then fill the rest of the first couple rows with calculations. And that's it.

I copy my last completed row down to the rows below, for each year of the model's life, 50 years maybe.

The trick is to plug in the right calculations. Those calcs want to mimic the actual relations between GDP and Debt and Additions to Debt and stuff, or what I imagine those relations to be. You know: If we spend a little less, we save a little more this year, but our reduced spending could affect GDP next year. Those kinds of relations.

When the bug bites I'll set up a spreadsheet like that and mess with it for a while, changing calculations, adding columns for new quantities, and looking at graphs of the resulting data.

I never manage to get graphs that mimic graphs of economic data. So I play with it for a while, then set it aside.

After I wrote the notes above, I went and read the first few pages of Clopper Almon's The Craft of Economic Modeling. Actually, Clopper says "The first section of chapter 1 does not require the use of computers." I printed out those six pages, so I could hold them in my hand.

Looking at the equations like

C = .6*Y[1] + .35*Y[2]


Q = C + I + G + X - M

where C is Consumption and Q is output, it occurred to me that each of the equations in the model could fit to a column of my spreadsheet. You copy the equation down the cells of the column to get each year's number. Oh -- you leave out the Q to the left of the equal sign, and you put the equation in the column that you have labeled Q!

Do you know how long it took me to figure that out???

So each of the equations in a model can be a column in a spreadsheet. Understanding this helps me understand economic models. What I've been doing for all these years is making a column for each variable I want to calculate, and then fudging the equations without ever really getting to look at the equations. I would start out with something that made sense to me, and keep filling in blanks until I had two or three rows worked out, then copy the last row down to represent 50 years or so, and then graph it.

Then I'd look at the graph, decide it didn't look right, and start tweaking my equations. First it would be adding columns to get more variables, and then working those variables into calculations and copying them to the rows below. Then it was things that made less sense, but might have some bearing. After a while it would be acts of desperation, just trying to come up with numbers that would produce a graph I could live with. And then I'd put the thing aside for a while.

I think it's probably better to pull out the equations so you can look at them like Clopper does, like I always see when somebody is describing a model.

But at least now I know: If there's two equations I need two columns in a spreadsheet for variables; if there's six, I need six.

No, no -- I'm not going to work only in spreadsheets. I want to download the free G7 software and learn how to use it. But I have to get there at my own pace. And I have to start with what I know.

Spreadsheets it is, then.

Tuesday, November 18, 2014

how to understand an economic model

So I finally Googled how to understand an economic model, something I really need to understand.

It was the article of the week at Reddit that drove me to it. I didn't read the linked article, just the comments on it at Reddit. Integralds lays out an overview of growth theory, of the development of growth theory, what standerby calls a "timeline of thought". It's easy reading, just a summary of developments. But it's impressive.

I didn't even click on any of the links. It wouldnt do me any good. Every time they start laying out a model my brain becomes impenetrable. Said to myself I need to know how to understand an economic model. Next thing I knew, it was Googled.

The fourth item in the Google results -- and the first one I hadn't been to before -- was The Craft of Economic Modeling, Part 1 (PDF, 149 pages) by Clopper Almon. Here's two bits of it, from the intro:
Simply put, an economic model is a set of equations which describe how the economy or some part of it functions. In my view, a model should incorporate and test our understanding of how the economy works. Its equations should make sense. And it should be possible to test how adequate our understanding is by running it over the past and seeing how well it can reproduce history. By changing some of its assumptions and rerunning history with the changed assumptions, it is possible to analyze the effects of policies. Finally, it should be useful not only for policy analysis but also for forecasting. By studying the errors of the forecast, the builder of the model may hope to improve his or her understanding of the economy.

Some of the equations in our models have constants which describe the behavior of firms, consumers, or other economic agents. These constants, often called "parameters", must somehow be estimated. The most frequently used way is by choosing them so that the equation describes accurately the behavior of those agents in the past. Thus, estimating the parameters is just a way to sum up the lessons of the past to forecast the future or examine how the past itself might have been different had different decisions been made. A large part of this book is about how to do that...

Yeah, I have to read this. I know, 149 pages. Usually if the page count is more than a single digit I start to worry. But I have to read this.

Oh yeah, one more thing:
The computer software, the G regression package, version 7.3, (referred to as G7) and the Build model builder, are comprehensive, easy-to-use programs that run under Windows XP and Windows 7 or 8. They are designed for work with time-series data. Public domain versions accompany the book or are available via Internet (www.inforum.umd.edu), where thousands of economic time series are also available as data banks for G7. Assembling equations into a model requires the use of the Borland C++ compiler, which is also available for free download...

Oh, my.

Monday, November 17, 2014

"An extremely persistent slowdown in long run growth rates since the 1970s"

Gavyn Davies, from his blog at FT:
NOTE: Davies' two "here" links didn't work for me, so I disabled them.
Three of my colleagues at Fulcrum have been examining the behaviour of long run GDP growth in the advanced economies, using developments of dynamic factor models to produce real time estimates of long run GDP growth rates. See the summary paper here by Juan Antolin-Diaz, Thomas Drechsel and Ivan Petrella, and the more academic version here.

The results (Graph 1) show an extremely persistent slowdown in long run growth rates since the 1970s, not a sudden decline after 2008. This looks more persistent for the G7 as a whole than it does for individual countries, where there is more variation in the pattern through time.

Averaged across the G7, the slowdown can be traced to trend declines in both population growth and (especially) labour productivity growth, which together have resulted in a halving in long run GDP growth from over 4 per cent in 1970 to 2 per cent now.

Impressive graph.

EDIT: Crossing things out:
I remember, probably 30 years ago, reading a review of a book by Glynn and Gavyn Davies. It was... At the time, the name of the book reminded me of Sidney Homer's A History of Interest Rates. I think the title was A History of Money. Glynn was Gavyn's father. This is all from memory; I could have it all wrong.

There ya go. The title: A History of Money: From Ancient Times to the Present Day. Author: Glyn Davies, only one "n". Maybe Gavyn wrote the review? I definitely remember both names. First published in 1994, according to Amazon; I was way off on the date. Price of the hardcover book, new, at Amazon? "From $2000". Oh, maybe that's why I didn't buy the book.

Anyway, that graph is huge.

Sunday, November 16, 2014

Rooting for inflation?

From VOX: The NAIRU, explained: why economists don't want unemployment to drop too low by Matthew Yglesias:
A middle ground would be to argue that perhaps the NAIRU did correctly characterize the economy of the 1970s. Back then, after all, a large share of the American workforce was represented by labor unions. Union contracts often included clauses that provided for automatic raises in the case of inflation. It's easy to see why any particular person would love to have such a clause in his contract. But it's also easy to see how widespread use of such clauses could inadvertently set off a spiral. Whether or not this was the case three or four decades ago, it's not a major issue in the American economy today, when many fewer workers have such contracts.

That's the whole paragraph. Here's the piece of it that's relevant for today's post:

It's not a major issue in the American economy today,
when many fewer workers have such contracts.

If you're thinking a little more inflation would help reduce our debt, you might want to think about whether your paycheck would be seeing that inflation. Debt doesn't inflate when wages inflate, so inflation can be helpful (though I do not favor that solution). But if prices inflate and wages do not, increasing inflation will leave us in worse shape than we're in now.

Saturday, November 15, 2014

"The role of the state in economic growth"

From the Abstract of The role of the state in economic growth (PDF, 59 pages) by Erik S. Reinert:

This paper attempts to trace and describe the role played by the government sector -- the state -- in promoting economic growth in Western societies since the Renaissance. One important conclusion is that the antagonism between state and market, which has characterised the twentieth century, is a relatively new phenomenon. Since the Renaissance one very important task of the state has been to create well-functioning markets by providing a legal framework, standards, credit, physical infrastructure and -- if necessary -- to function temporarily as an entrepreneur of last resort.

Friday, November 14, 2014

Real Adjusted Total Bullshit

Some time around 1994 apparently they changed the definition of M1 money. Before 1994 the definition of M1SL money included "sweeps". After 1994 it didn't.

So now, if you want to look at the same money measure before and after 1994, you have to look at what's called "M1 Adjusted for Retail Sweeps", or M1ADJ.

But this nomenclature is wrong. It's backwards. They changed the definition of M1 money, M1SL. That was the change. So when you look at M1SL, what you see after 1994 is not the same measure as before 1994. When they made the change, they should have made a new series to show the new numbers. This new series is the one that should have been called "adjusted for retail sweeps". I should be able to look at the old M1 money series M1SL and not see numbers that change suddenly and dramatically because of the adjustment.

Graph #1: M1SL (blue) and M1ADJ (red)
The data series title "M1 Adjusted for Retail Sweeps" implies that the change occurs in the M1ADJ data series, when really the change occurs in M1SL, the data series whose title makes no mention of the adjustment.

This is exactly the same kind of deceptive language you get when economists take GDP -- a measure of the stuff we actually bought, at prices we actually paid for it -- when they take GDP, and take the inflation out of it, and call the result "real" GDP.

Total bullshit.