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.

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

BUG: Including 0 in wealth and consumption grid #11

Closed
MImmesberger opened this issue May 10, 2023 · 4 comments
Closed

BUG: Including 0 in wealth and consumption grid #11

MImmesberger opened this issue May 10, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@MImmesberger
Copy link
Member

Problem description

On this branch, I test the results of lcm against the analytical solution by Iskhakov et al. (2017). In this model, agents face a discrete retirement decision (absorbing state) and a continuous consumption decision.

When testing the value function of lcm, I set up the model in the following way. Note that the wealth and consumption grid starts at 0 and there are T=3 periods.

I included 0 in the consumption and wealth grid because I think this is necessary in order to correctly test the numerical results against an analytical solution. Else, retired agents being in the n-1 lowest possible states (in an n period problem with equal consumption and wealth grid) would necessarily violate their budget constraint, which produces incorrect results that may spill over to the other states.

from lcm.example_models import PHELPS_DEATON_NO_BORROWING
from lcm.entry_point import get_lcm_function

model = PHELPS_DEATON_NO_BORROWING
model["n_periods"] = 3
model["choices"]["consumption"]["start"] = 0
model["choices"]["consumption"]["stop"] = 100
model["choices"]["consumption"]["n_points"] = 10_000
model["states"]["wealth"]["start"] = 0
model["states"]["wealth"]["stop"] = 100
model["states"]["wealth"]["n_points"] = 10_000
solve_model, params_template = get_lcm_function(model=model)

params_template["beta"] = 0.98
params_template["labor_income"]["wage"] = 20.0
params_template["next_wealth"]["interest_rate"] = 0.0
params_template["utility"]["delta"] = 1.0

numerical_solution = solve_model(params=params_template)

The value functions of the first two periods (for the retired agent) seem to be wrong. The last period value function is correct.

Value function in period 2

For the initially retired, I get the following result for the value function on the wealth grid:

[ -inf , -inf, -9.118039 , ..., 7.7455106, 7.7457085, 7.745907 ]

The correct/analytical solution would be:

[-inf, -10.49036936,  -9.11793795, ..., 7.74551444, 7.74571051, 7.74590656]

The -inf in the second entry is due to the value function being computed on a grid, this doesn't show up in the analytical solution (only the first -inf entry is correct). What surprises me is that the following values on the grid are imprecise as well. When working on a grid with 10_000 grid points, only after the 800th or so grid points, results are always close up to 5 or 6 decimals. Maybe the issues at the first few grid points induce numerical imprecision somehow?

The solution for the workers coincides with the analytical solution.

Value function in period 1

I get a list of nan, both for the initially retired and for the agents still working. This problem does not occur if the minimum grid value is larger than 0.

@MImmesberger MImmesberger added the bug Something isn't working label May 10, 2023
@timmens
Copy link
Member

timmens commented Oct 9, 2023

Changing the label from bug to enhancement, as we've noticed that these issued can be circumvented by using a very fine wealth grid. The enhancement must deal with the actual zero case.

@timmens timmens added enhancement New feature or request and removed bug Something isn't working labels Oct 9, 2023
@hmgaudecker
Copy link
Member

I am not sure we'll ever want this. Why would we want to support a grid value where the utility function is undefined?

@timmens
Copy link
Member

timmens commented Feb 19, 2024

I think it matters whether the utility value is actually undefined, or if it is negative infinity. I guess in the former case, LCM should throw an error, but in the latter, LCM should be able to handle the case without introducing NAs.

Nevertheless, I think once we decide on which behavior we expect from LCM we can open a new Issue requesting it and close this Issue.

@timmens
Copy link
Member

timmens commented Feb 19, 2024

After talking to @hmgaudecker, we realized that we also do not want to handle the "negative infinity" case, but want to throw an error in both cases. Moved to #55.

@timmens timmens closed this as completed Feb 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants