adding test for default solution to PerfForesightConsumerType

[sbenthall]

See #504

This PR tests the results of the solution to a PerfForesightConsumerType problem, using the default parameters.

It adds the test to the unit tests that are run by Travis CI.

One thing that is not ideal about this test is that it is taking the output it is testing against from the result of an execution of the existing code.

That means that this test will fire if the underlying code changes in a way that changes to solution value.

But it could be possible to do better, especially in this particular case, in which the solution has a closed form in terms of the agent model parameters.

[mnwhite]

I totally missed that this was outstanding. Yes, let's eventually update this test to use the known closed form solution to the infinite horizon perfect foresight problem. But I'm glad this exists.

…

On Wed, Feb 26, 2020 at 1:33 PM Sebastian Benthall ***@***.***> wrote: Merged #506 <#506> into master. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#506?email_source=notifications&email_token=ADKRAFNICISAIUALTEN6A7TRE2YY7A5CNFSM4KSEW3BKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOW5DZAXI#event-3074920541>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFN76QIYYAAFLCVLQSLRE2YY7ANCNFSM4KSEW3BA> .

[llorracc]

Definitely this is a case where the closed form solution should be used.

Actually, it's always seemed to me that we should simply use the closed form solution directly as the output of this; really the only advantage of solving it numerically is precisely as a simple test of whether there are bugs in our numerical algorithms.

[mnwhite]

The closed form solution only works if it's infinite horizon, one period cycle, no artificial borrowing constraint; we can't switch to it as a general policy. I'd say we want to use the numeric solver for backward iteration even when it's not mathematically necessary both for consistency *and* for teaching/exploration purposes. If you still want to do this, what we would do is add a method that's called by preSolve() if it's both infinite horizon and a one period cycle; the method would alter solution_terminal to have the closed form unconstrained cFunc, regardless of whether there's a borrowing constraint. If the problem is unconstrained, it will converge in 1 or 2 cycles (I can't remember if it's still set to not check for convergence after the first iteration) and be exactly correct. If the problem is constrained, starting with the unconstrained infinite horizon solution actually makes the final result more accurate.

…

On Wed, Feb 26, 2020 at 7:16 PM Christopher Llorracc Carroll < ***@***.***> wrote: Definitely this is a case where the closed form solution should be used. Actually, it's always seemed to me that we should simply use the closed form solution directly as the output of this; really the only advantage of solving it numerically is precisely as a simple test of whether there are bugs in our numerical algorithms. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#506?email_source=notifications&email_token=ADKRAFNFMXIXIFD2TBIKVADRE4A7DA5CNFSM4KSEW3BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCMWJQ#issuecomment-591711014>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFN5HVD6ZYW5VGYAJPLRE4A7DANCNFSM4KSEW3BA> .

[llorracc]

There’s a closed form solution for the finite horizon model too: PerfForesightCRRA <http://econ.jhu.edu/people/ccarroll/public/lecturenotes/consumption/PerfForesightCRRA> ( http://www.econ2.jhu.edu/people/ccarroll/public/lecturenotes/consumption/PerfForesightCRRA/#cFuncAnalytical ) and for the perfect foresight model with an artificial liquidity constraint: LiqConstr <http://www.econ2.jhu.edu/people/ccarroll/papers/LiqConstr/> In practice, either of these solutions should be instantiated in a piecewise linear interpolator. It occurs to me now that you may have misinterpreted me when I said we should use the closed form solution where it exists. I did not mean that we should do, like, a lambda function that embodies the equation in the first link above, which would only e evaluated at the instant when it is needed (substituting in the coefficients at that stage). I just meant that we might prefer not to use a completely generic solution method, and instead .solve() would hand-construct the points for the interpolating functions, using exactly the right kink points etc. If it were costless, I guess the ideal solution would be to have an optional “useClosedForm” boolean which could (per your preference) default to false but when True would: 1. Check whether the conditions required for the closed form solution are met; - If not, produce a warning message and return the numerical solution - If so, return the answer constructed using the closed form solution On Thu, Feb 27, 2020 at 3:20 AM Matthew N. White [email protected] <http://mailto:[email protected]> wrote: The closed form solution only works if it's infinite horizon, one period

cycle, no artificial borrowing constraint; we can't switch to it as a general policy. I'd say we want to use the numeric solver for backward iteration even when it's not mathematically necessary both for consistency *and* for teaching/exploration purposes. If you still want to do this, what we would do is add a method that's called by preSolve() if it's both infinite horizon and a one period cycle; the method would alter solution_terminal to have the closed form unconstrained cFunc, regardless of whether there's a borrowing constraint. If the problem is unconstrained, it will converge in 1 or 2 cycles (I can't remember if it's still set to not check for convergence after the first iteration) and be exactly correct. If the problem is constrained, starting with the unconstrained infinite horizon solution actually makes the final result more accurate. On Wed, Feb 26, 2020 at 7:16 PM Christopher Llorracc Carroll < ***@***.***> wrote: > Definitely this is a case where the closed form solution should be used. > > Actually, it's always seemed to me that we should simply use the closed > form solution directly as the output of this; really the only advantage of > solving it numerically is precisely as a simple test of whether there are > bugs in our numerical algorithms. > > — > You are receiving this because your review was requested. > Reply to this email directly, view it on GitHub > < #506?email_source=notifications&email_token=ADKRAFNFMXIXIFD2TBIKVADRE4A7DA5CNFSM4KSEW3BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCMWJQ#issuecomment-591711014 >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ADKRAFN5HVD6ZYW5VGYAJPLRE4A7DANCNFSM4KSEW3BA > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#506?email_source=notifications&email_token=AAKCK77XIJRGEGI7N2VNM6LRE4POPA5CNFSM4KSEW3BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCUZRA#issuecomment-591744196>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK7ZDXNKSHES5WNJHYMLRE4POPANCNFSM4KSEW3BA> .

-- - Chris Carroll