Why is absolute vP (derivative of value function) the default convergence criterion?

[llorracc]

Seems like a more natural choice would be the average size of Euler equation errors. They are scaleless. You can multiply or divide the value function by a constant and the absolute size of the errors will change, but that has no meaning for the accuracy of the solution.

[mnwhite]

The marginal value function vPfunc is defined by the pseudo-inverse marginal value function vPnvrsFunc (an attribute of itself). This function is identical to cFunc, because of the envelope condition; in fact, that's what's passed as vPnvrsFunc when vPfunc is constructed. So the convergence criterion is really looking at cFunc, and the default convergence value of 1e-6 means that no interpolation node of the consumption function has changed by more than one millionth of permanent income since the last iteration.

Setting convergence to use Euler equation errors has a few problems:

1. It would require the code to evaluate the numerical integrals twice per iteration: first when actually computing EndOfPrdvP as usual, and then again to test the newly constructed cFunc against itself. This would double computation time.

2. We would need to rewrite the core code a little to allow the solver to know whether it's part of a finite or infinite horizon problem. We don't want the finite horizon problem to test cFunc_t against itself for Euler equation errors, which is nonsensical.

3. This whole process really can't be done within the solver, because we don't actually want cFunc_t compared against itself in all infinite horizon models; that's only the relevant comparison if it's a "one period" infinite horizon problem. So we'd need a wholesale restructuring of HARK to do this.

There are other issues, but I hope I've convinced you this is not the right approach.

[llorracc]

You had me substantively when you said that the convergence criterion was really looking at cFunc. That's actually what I thought it should be, and Euler errors were just a step in that direction.

The only residual point is that it would be good if it were more transparent that this is what the criterion is. I wasn't able to figure that out from my cursory reading of the code.

Could you edit whatever you think is the appropriate docstring, and/or put in a comment wherever you think it would be most likely to be useful to someone trying to quickly understand the convergence criterion?

[mnwhite]

Ok.

…

On Sun, Jan 26, 2020 at 10:36 AM Christopher Llorracc Carroll < ***@***.***> wrote: You had me substantively when you said that the convergence criterion was really looking at cFunc. That's actually what I thought it should be, and Euler errors were just a step in that direction. The only residual point is that it would be good if it were more transparent that this is what the criterion is. I wasn't able to figure that out from my cursory reading of the code. Could you edit whatever you think is the appropriate docstring, and/or put in a comment wherever you think it would be most likely to be useful to someone trying to quickly understand the convergence criterion? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#447?email_source=notifications&email_token=ADKRAFJ4Y26CSB5NE5SZMRLQ7WUZBA5CNFSM4JXNLOLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5WVDY#issuecomment-578513551>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFOQCVDITG5NZNE3ZCLQ7WUZBANCNFSM4JXNLOLA> .