separableReturnFn for finite horizon

Hi Rob,

Wanted to ask if you could add this block of code

%% Separable Return Fn
if vfoptions.separableReturnFn==1
    % Split it off here, as messes with ReturnFnParamNames and ReturnFnParamsVec
    [V,Policy]=ValueFnIter_FHorz_SeparableReturnFn(n_d,n_a,n_z,vfoptions.n_semiz,N_j,d_grid,a_grid,z_gridvals_J,vfoptions.semiz_gridvals_J, pi_z_J, vfoptions.pi_semiz_J, ReturnFn, Parameters, DiscountFactorParamNames, ReturnFnParamNames, vfoptions);
    varargout={V,Policy};
    return
end

in ValueFnIter_Case1_FHorz around line 280, after the block %% Semi-exogenous shock gridvals and pi and before the block %% Implement new way of handling ReturnFn inputs.

I’m implementing something similar to what we did in the infinite horizon version, this time for finite horizon with semi-exogenous shocks.

I think it shouldn’t bother any other user, but feel free to reject my proposal if you think it does not fit with the toolkit :slight_smile:

Thanks!

1 Like

Happy to add, please send me a copy of ā€˜ValueFnIter_FHorz_SeparableReturnFn.m’ and I will put it all into github.

[I don’t want it to be a ā€˜missing’ command, but am happy to include the command you write in there as something people can access via vfoptions.]

1 Like

Great, thanks!

I’ll prepare a polished function and send it to you via e-mail, then. A couple of questions: (1) I thought of doing it for semi-exog only, is that OK? (2) In my experience, it is safer to pass also the return fn params names as a cell array of characters. The new way of dealing with param names works really nice for standard commands, but when you have ReturnFn1 and ReturnFn2 becomes tricky. Do you think is OK as a first pass?

As long as other than adding the ā€œif vfoptions.separableReturnFn==1 …. endā€ lines into ValueFnIter_Case1_FHorz() is the only change to ValueFnIter_Case1_FHorz(), that is all good.

1 Like