EconForge / dolo.py

Economic modelling in python
BSD 2-Clause "Simplified" License
98 stars 72 forks source link

We're using a d.r. object for value function for instance #190

Open sbenthall opened 4 years ago

sbenthall commented 4 years ago

https://github.com/EconForge/dolo/issues/188#issuecomment-597239070

albop commented 4 years ago

In my opinion, this is not really a bug, since we consistently call "decision rule" a function f(m,s) where m is a vector of exogenous states, and s a vector of endogenous states. Also note that there is a little bit of flexibility in the naming: what we call control is not necessarily the control of a controlled stochastic process (it can also be a price in an equlibrium model with two agents), and you could perfectly treat a value as a regular control to be solved using time iterations... Now, I'm sympathetic with the idea of using another name to denote function f(m,s) , but I'm not clear about what that name would be. Function is not specific enough (and we use it for all kind of purposes like the accepted functions in a yaml file: sin, cos, etc.). One could think of concepts like fields, surfaces varieties, but they would all be more confusing. On the other hand, I don't see any reason to not define a special value function object with to be returned by VFI algorithms and other. Easiest way to do would be class ValueFunction(DecisionRule): pass until a better parent object is defined. Beyond naming, a potential advantage, of using a different kind of object could be to optionally exploit some known math property of the value function, like concavity, and use, for instance, shape-preserving splines.