Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a not-too-general value backwards induction algorithm built on DBlocks #1438

Open
wants to merge 20 commits into
base: master
Choose a base branch
from
+359 −17
Open

a not-too-general value backwards induction algorithm built on DBlocks #1438

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
d529a44
sketch of a general value backwards induction algorithm built on DBlocks
sbenthall Jun 3, 2024
431fc80
ruff
sbenthall Jun 3, 2024
fd603b5
fixes for doc errors
sbenthall Jun 3, 2024
b1daaff
adding algos to docs table of contents
sbenthall Jun 3, 2024
510acaf
automated test for vbi solution algorithm
sbenthall Jun 4, 2024
219b03c
Merge branch 'master' into algos-b
sbenthall Jun 4, 2024
7b0bf4f
changelog for vbi solver in 0.16.0 release now
sbenthall Jun 4, 2024
0e9300c
first try at adding upper bound information to consumer model
sbenthall Jun 4, 2024
1770ab0
using lower and upper bounds given to Control in vbi algorithm; passi…
sbenthall Jun 5, 2024
aba2c55
passing disc_params to consumption block vbi solver test
sbenthall Jun 5, 2024
e676627
ruff fixes
sbenthall Jun 5, 2024
3e90f64
fixing the general model tests -- 'screening' transition is optional
sbenthall Jun 5, 2024
32eb4c1
documentating optional screening of transition function
sbenthall Jun 5, 2024
7fb5553
Merge branch 'master' into algos-b
sbenthall Jun 12, 2024
6ec5d5e
touch ups
sbenthall Jun 18, 2024
8b43ca2
Merge branch 'master' into algos-b
sbenthall Jun 18, 2024
7040c44
don't need to initialize income in normalized models
sbenthall Jun 18, 2024
1e22c86
Merge branch 'master' into algos-b
sbenthall Nov 14, 2024
61fd2f7
vbi algo handling cases where stage has 0 controls
sbenthall Nov 14, 2024
8f45b79
rufff fixes
sbenthall Nov 14, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions HARK/model.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,12 +31,13 @@ class Control:

Parameters
----------
args : list of str
iset : list of str
The labels of the variables that are in the information set of this control.
"""

def __init__(self, args):
pass
def __init__(self, iset, upper_bound=None):
self.iset = iset
self.upper_bound = upper_bound


def discretized_shock_dstn(shocks, disc_params):
Expand Down
2 changes: 1 addition & 1 deletion HARK/models/consumer.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@
"dynamics": {
"b": lambda k, R, PermGroFac: k * R / PermGroFac,
"m": lambda b, theta: b + theta,
"c": Control(["m"]),
"c": Control(["m"], upper_bound=lambda m: m),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mnwhite @alanlujan91 I wonder what you think about this way of introducing upper/lower bound information on control variables.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks good.

If we wanted to differentiate between a fixed (real number) upper bound, and a functional upper bound, we could use the term upper_envelope for a function/lambda.

"a": lambda m, c: m - c,
},
"reward": {"u": lambda c, CRRA: c ** (1 - CRRA) / (1 - CRRA)},
Expand Down
Loading