Background
More than anyone, Steve Keen has raised awareness of the role of banking and money creation in driving economic cycles. Not only this, he has published just about every presentation and paper of his freely online, and participated in a variety of forums online and in the media.
Not only is he out there putting forward new approaches and ideas, he is doing so in a way that allows every man and his dog to nit pick at his work. That takes guts.
Because of public nature of his work for the past decade, his analysis and communication of these big ideas has evolved to become extremely powerful and hard to ignore. Just about everyone I talk to in the economics crowd these days has been influenced by Keen’s work in some way. Even I am still digesting his reconciliation of accounting identities and the dynamic effect of additional demand from credit creation, which I think could offer a clear path forward for gaining wider acceptance of his dynamic monetary methods.
The issue
In the spirit of this public debate I want to take issue with one of Keen’s latest ideas; adding change in credit (debt) to GDP. But I want to do so constructively so that as a profession we can incrementally improve our economic analysis and understanding of macroeconomic phenomena.Fresh Economic Thinking
A comment on Keen’s “Credit plus GDP” measure
Cameron K. Murray
See also
16 comments:
X = X + 1
X = X + 1 NW
A perfectly valid computer command* and Steve Keen is a computer modeler.
*to writ: Increment the value stored in X by 1.
LET X = X + 1
LET X = X + 1 Bob
In BASIC, yes. In other languages such as FORTRAN and C, X = X + 1 is a correct command.
My favorite is x++.. some will argue ++x is better, and they're probably right but I like the aesthetics of x++ better. Totally pointless comment, I know, but programming is my day job.
My favorite is x++.. some will argue ++x is better, and they're probably right but I like the aesthetics of x++ better. Joe
I used to program in C, 14 years ago. Thanks for the blast from the past! Pre or post inc(dec)rement has do with the order of precedence wrt syntax and is useful when using pointers, if I recall correctly. They can be quite different in effect, iirc.
Yup, order of precedence. But in the case of
for (int x=0;x < somevar; x++)
Some will argue for ++x even though it ends up the same, I can't remember their reasoning, must not have been all that persuasive... but yeah something like y=++x + 5; is different than y=x++ + 5..
but yeah something like y=++x + 5; is different than y=x++ + 5.. Joe
Maybe you mean y=++x* + 5; is different than y=x++* + 5; ? (It's been a LONG time!)
Of course, looking at the machine code is the bottom line test of what's going on though the assembler code should be indicate the same thing.
Well, now we've got our revenge for having to learn accounting jargon with some punishing jargon of our own! :)
Nope. Say we have
int y, x=3;
y = ++x + 5; //y will be 9 and x will be 4. X is incremented and then 5 is added
x=3; // reset x
y = x++ + 5; //y will 8 and x will be 4. 5 is added to x and stored in y, and then x is incremented
I looked it up, the reason to use ++x over x++ in situations where it seemingly makes no difference (like the for loop above) is that x++ could create a copy of x before incrementing whereas ++x does it in place. So with x++ there's the possibility of needing an extra memory allocation and a copy. With primitive types like int, it won't matter since the compiler will almost certainly optimize it, but with more complex objects, creation and copying could be expensive, so it could become relevant when iterating over a collection of objects.
In case you are using a complex type, you are overriding the operator behaviour and you define the underlying addition behaviour and whereas values are copied or moved so... that is in C++ (or other modern languages), as C doesn't support operator overloading AFAIK.
Is a mess to do both an assignment and an addition in the same expression precisely because it could cause unwanted behaviour that is nightmarish to debug later on though. So as 'fun' exercise it's ok, but don't use that shit on production code please ;)
*I mean an assignment/addition to/from two different variables on the same expression
I agree ignacio... operator overloading is generally a bad idea (and it's not available in c), cause what the hell does it mean to increment some complex type? Say you have an object representing a car, what's it mean to add two cars together? Who the hell knows..Throw memory allocation and pointers into the mix and you have to worry about copy constructors, deep & shallow copies, being careful to not double delete a pointer, or forgetting to delete etc, and you're really quick into the weeds of all the subtleties of c++.
One exception is graphics and math programming where it's natural to add and subtract vectors and multiply matrices.
Thanks Joe and thanks Ignacio. I doff my imaginary hat to you both.
One wonders why scientists and engineers haven't fixed the current "money system" and my suspicion is that they're too honest to comprehend how crooked it is without severe nausea.
"The mind is repelled" to quote James K Galbraith.
The keyword LET is optional in many flavours of BASIC, but it may help non-programmers understand what is happening.
LDX #FF
INX
Make that John Kenneth Galbraith and the complete quote is "The process by which banks create money is so simple that the mind is repelled."
Seems like an interesting guy.
Post a Comment