tag:blogger.com,1999:blog-5908830827135060852.post6904782554683538721..comments2020-05-30T23:13:47.028-04:00Comments on Bond Economics: Equations In Stock-Flow Consistent ModelsBrian Romanchukhttp://www.blogger.com/profile/02699198289421951151noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5908830827135060852.post-50773830311012340122017-12-11T07:00:09.328-05:002017-12-11T07:00:09.328-05:00Looking at what I wrote, I should have reworded my...Looking at what I wrote, I should have reworded my description; I was only referring to stocks and flows only; there could be other state variables. The problem is that we do not know when flows will be promoted to stocks, it may only happen at the final stage of model building,<br /><br />As for the discrete time behaviour changing, as a result of the time step redefinition, I think that’s relatively realistic. It implies that we need to re-estimate model parameters if we changed frequency. In my view, that is probably the expected behaviour. You can go from a high frequency to a lower frequency relatively safely, but not the other way around - we are missing information. This would be distressing if we had accurate continuous time models, as in circuit theory, be we do no have them in economics.<br /><br />To a limited extent, the distinction between state variables and ones that can be computed is buried in my solver. I use heuristics to determine which variables do not affect the other variables (“decorative”), and they are only calculated once we have iterated to the final solution.<br /><br />Calculating most interesting flows is also very difficult. A sector does not actually know what the expression for its after-tax income is until the model is built, since that depends upon which other sectors are present. Therefore, it cannot buld any equations which depend upon after-tax income until the final model binding stage, which is going to make the sector definition nearly impossible to understand. Instead, the sector just declares an after-tax variable, and uses it within equations. It knows that the final expression for after-tax income will be filled in later.<br /><br />In other words, it would be very confusing for users to not have access to flow variables during equation declaration. It might be possible to segregate such variables later, but I am unsure about the feasibility of that. I would need to impose more structure on the equations; currently, they end up as arbitrary Python functions (embedded in a string).Brian Romanchukhttps://www.blogger.com/profile/02699198289421951151noreply@blogger.comtag:blogger.com,1999:blog-5908830827135060852.post-69242774361704564822017-12-11T06:21:32.273-05:002017-12-11T06:21:32.273-05:00Brian,
Than you very much for engaging in the dis...Brian,<br /><br />Than you very much for engaging in the discussion and providing valuable explanations.Unfortunately I haven't made one point clear enough, let me re-state the argument again. I haven't said that only stocks are state variables. This is the reason my continuous-time implementation didn't work for 3 months. Stocks and expectational variables are state variables of a model. If we don't have expectational state variables we can't properly implement consumption from the current income in a continuous-time implementation of the same model. I am not arguing we have to use continuous time, discrete time is perfectly good for a computer and for me but this is a sanity check. A simple way to implement adaptive expectations is to use a 1st order integrator which integrates error signal between the current and expected values. We have a hidden stock variable there (the result of the integration). This is less obvious in a discrete-time model as past flows can appear on the right-hand side of equations. In this case these are delayed values - but previous values do not make sense in a continuous-time abstraction and we end up with the simultaneous determination problem. Flows "proper" can be evaluated from stocks and expectational variables at any point of time. Regarding the argument that "we could infer the savings in each period by just looking at the change in the stock, and drop the savings from our state space representation" it is rather the other way around. In a simple case current saving (a flow) is the difference between disposable income (a flow) and consumption (another flow). Disposable income is a sum of wages and dividends, which are determined by stocks and expectations. Consumption is determined by the expectations about the current disposable income (which hasn't been realised yet - it will be realised "in the next period" in period analysis) and the stock of wealth. If we convert a model to continuous time domain we instantly see that we cannot use "previous period" flows as these are equal (on limit) to current flows <br /><br />lim flow(t-delta t) = flow(t) for lim delta t = 0 <br />if flow(t) a continuous function at t<br /><br />in a discrete time model we usually have delta t = 1 year <br /><br />so flow variables should not be treated as state variables because the behaviour of the model depends on delta t. We can either use lagged expectations or time-delayed value of the flow which can be approximated with a high-order low pass filter.<br /><br />I promise to contribute more when I clear the backlog...<br /><br />I see a lot of value in the overall idea of the package and like the idea of test-driven development.<br /><br />Regards,<br />Adam KAnonymoushttps://www.blogger.com/profile/08667551884676442523noreply@blogger.com