Draft
Conversation
OLGModel14 attempts to solve a GE for households (with finite horizons) and firms (with infinite horizons). While there are plenty of functions for solving for one type of horizon or another, we must make some accommodations for mixtures of the two. Given there is already some code in the FHorz cases for the occasional infinite horizon, I attempted to flesh that out until the GE could be solved without throwing errors. I took the liberty of keeping InfHorz grids named without the _J suffix, just so we'd get an error if we sent the wrong parameters to the wrong function. I also saw what appeared to be minor drifts in the implementations of the two types of functions, and I copy/pasted what appeared to be the more elaborated code to the side that seemed to be missing it.
As an alternative to getInterpMatrix function, use the value exp(-500) as a zero-like value. When added to any "normal" floating point value it will read as zero, and when multiplied by an +/-Inf value it will preserve the +/-Inf value instead of converting it to NaN (which happens when multiplied by actual zero). Also, give a warning when Howards-greedy is given a `ReturnMatrix` containing an infinite value (it cannot handle that). And clean up some typos we found.
Return to resolving OLGModel14 changes needed to run. To wit: HeteroAgentStationaryEqm_Case1_FHorz_PType: add some clarifying comments about how we have moved code around to reduce duplication between FHorz and InfHorz cases that can be mixed together (as OLGModel14 does). HeteroAgentStationaryEqm_Case1_PType: Mostly clean and comment. Also remove error message related to no implemented functionality. Is it now implemented? ValueFnIter_nod_HowardGreedy_raw: if we should call this function without ever evaluating the return function (because `maxiter` was zero or some such, then `Ftemp` would never have been initialized. I restored the test for non-finite values inside the loop because testing a matrix that's `n_a` by `n_z` is relatively cheap, and it's very valuable for people to see the moment the bad value pops up (for easier debugging).
In my particular case, the toolkit was trying to allocate overly large arrays when `lowmemory==2` was selected. Specifically: ``` DiscountedEV=DiscountFactorParamsVec*repelem(EV,N_d1,N_a1,1); ``` Replicated a large `EV` N_d1 times N_a1 times is unnecessary, as the loop for `lowmemory==2` doesn't use all of EV, but iterates across the `z`s (as well as the `e`s. I noticed that other ExpAsset codes already had the fixes I am proposing herein (namely, replicate based on `EV(:,:,z_c)` rather than all of EV and then selecting the `z` elements from that). I also noticed that other codes had optimizations like lifting some array constructions out of loops, etc. I attempted to therefore coalesce the best of all across all in this directory. There's obviously more work to be done for more code cases, but I thought I'd start with this bite-sized chunk. Normally I'd create a fresh branch for these changes and a clean pull request. But I need these changes in the OLGModel14-mixed-horizon-fixes branch, which might need a while before its merged. So I'm leaving it to you to decide whether you want to `git cherry-pick` this commit and merge into the main branch ahead of that decision.
This change implements support for CustomModelStats when `heteroagentoptions` has PType specifiers (i.e., `heteroagentoptions.household.CustomModelStats`). In this implementation, we can support CustomModelStats for each different PType, separately. This is a simple case because each PType is only either FHorz or InfHorz. It does not yet support a overarching PType implementation whereby a single CustomModelStats can see all PTypes at once. This case is more difficult, as different PTypes can have different horizons, thus a universal CustomModelStats function would have to unpack that before calling magical subfunctions.
…ichaelTiemann/VFIToolkit-matlab into OLGModel14-mixed-horizon-fixes
These are relatively minimal changes needed to graph the transition paths across OLGModel14.
There's one innocuous change related to handling `experienceasset` in `vfoptions`, but these changes have none of the work I've tried to do to make experienceassets work with transition paths. That work will come later.
There are a few cases where I could not help but reformat some code (isa(X,'struct') -> isstruct(X)), and also Names_i{ii}->iistr where appropriate. But otherwise they are about as minimal as I could make them.
I have created `TransitionPath_InfHorz_PType_singlepath.m` which could easily be used to simplify the guts of `TransitionPath_InfHorz_PType_shooting.m`, but that, too, will wait for a later day.
Previous version got us our first graph, but then failed in later iterations. This seems to work more robustly. Now we need to figure out why our transition doesn't converge. Likely because I haven't let the GE solver do its job. (Fast was better than good while working out the code paths. Now we need to see what good really looks like...)
First we fixed everything through `TransitionPath_Case1_FHorz_PType` This change fixes everything through `AgentDistOnTransPath_Case1_FHorz_PType` and `EvalFnOnTransPath_AggVars_Case1_FHorz_PType`.
Because this file handles general PType structures (even though it's name doesn't say so), we should not look for age-like shapes when `N_j_temp` is `Inf`.
Initial testing didn't have `e` grids. New testing does.
There were a few vestigial uses of `transpathoptions.maxiterations` where most of the code uses `transpathoptions.maxiter`. All are now consistent.
… for _tminus1 AggVars Replaced the previous DNA transplant with better DNA transplant. In addition to sorting out the correct shapes of the Policies so that AgentDist did not immediately diverge, also added PType support for AggVars using _tminus1 functionality.
Fix the for loop structure attempting to align `GeneralEqmEqns` (using iterator `gg`) with `GEPriceParamNames` (using iterator `pp`) via the table join `options.GEnewprice3.howtoupdate` (using iterator `gg2`). I don't quite understand how the `PricePathSizeVec` is constructed, so don't know how to make a test case that creates the expected `N_i` spacing. But even without the test case, I think this loop works as intended, whereas the previous one did not.
When I attempted to merge TransitionPath_Case1_FHorz, I misunderstood a detail about reshaping arrays and the way that AgentDist_initial interacted with AgeWeights_initial. Now sorted. Also fixed some other small but obvious mistakes (my own and others').
Make these three files consistent with all others in terms of using `ttr` as the iterator name calculating the value function and optimal policy at each step from T-1 to 1. Later, when we change this to actually stepping backwards, all the `ttr`s should be changed at the same time to start at T-1, walking backwards, with `ttr` instead of `T-ttr` used within the loop.
There are many places where Z is tested against 0 for reshaping purposes. It could equivalently be testing against <2, because the reshape for z==1 is the same as for z==0. If this is accepted, there are many other cases that could be similarly changed.
We need to set the V0 guess earlier to handle some tests that come later (but before V0 had been set/reshaped in the original code).
MATLAB 2025a supports reshaping sparse gpuarray, but not isnan(sparse(gpuarray)). So make full before allocating to gpuArray.
Don't give error about not finding a parameter until we've exhausted the PTypes looking for it.
When testing code with a trivial Z grid (only 1 single element), bugs were revealed in both the comments and the code. These changes fix that. They also take the liberty of unifying some common code.
The changes expand the range of the VFI Toolkit to handle an experience asset with `length(n_a)==5`, following accepted changes to support experience asset with `length(n_a)==4`. To handle exponentially increasing grid sizes, changes are proposed to `ValueFnIter_FHorz_ExpAsset_raw` (and its `_e` variant) to treat the experience asset as something that can be iterated when `lowmemory==2`, either instead of or along side the iteration of `e` shocks. In the course of testing, a transcription error was disovered in `CreateGridvals` when `l_x`==5. And for my own testing purposes, I needed to manually expand the options accepted by `EvalFnOnAgentDist_Grid_J`, though I'm sure that a better solution is to run the code generator used to generate the guts of this file to support `l_daprime==7` across its many possible instantiations.
This just missed the previous commit.
Handle ExpAsset iteration using lowmemory=3, leaving lowmemory cases 1 and 2 untouched. Also add an error message in case user mistakenly tries to use lowmemory=2 without both z and e to iterate over.
If there's going to be only one special case, let it be the one I plan to use.
Prepare to merge in changes from last week that I didn't see coming. These changes seem to work for models that have z and e, but for the confusion about the joint ze grid in late-stage Transition Path evaluations. Making the changes work without any e ever should be easy, as should be making them work without z (and other necessary shapes).
Follow the conventions of ValueFnIter_Case1_FHorz to initialize `vfoptions.polindorval`.
We are now iteration through the solution space of transition convergence.
I'm back to testing `small_z_no_e`, so need cases that work there, too.
Satisfied with the first draft of supporting models with both z and e, now implement changes to support models with z and no e. Additional varieties can be implemented from these two as needed.
Use the appropriate DiscountParameterNames for the given PType.
A few fixes need to push upstream...
With these change, the program has iterated through initial and final GE and is running the transition convergence.
Easily enough done...
Easily enough done...
Changed iterator for `customstatnames` to match with `intEqnnames` and `AggVarNames`.
…nn/VFIToolkit-matlab into mixed-horizon-tpath
Don't try to be too clever when N_z==1 (treating it the same as when N_z==0). The efficiency is not worth the code divergence.
These are the non-ExpAsset changes needed thus far to progress a model through all the ptype and tpath things I have encountered.
Contributor
Author
|
Converting to draft, because it really depends on the PType/TPath pull request being accepted first. Once that is merged, I'll merge those changes into this, and it should reduce the changed file count from 58 to 38. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These are the changes to ExpAssets to enable a large model to use ExpAssets in a wider range of circumstances.
This is also a branch from which additional PType changes (and other changes) will be cherry-picked out for separate merging. When all those pre-requisites have been merged, this pull request should consist entirely of ExpAsset changes.
NOTE: Files such as
VFIToolkit-matlab\EvaluateFnOnAgentDist\TransPathFHorz\SubCodes\ExpAsset\EvalFnOnAgentDist_AggVars_FHorz_ExpAsset_fastOLG.mwhich come from code generators need to be modified to add the ExpAsset argument to thearrayfunfunction calls. I have manually fixed up thew few cases I have tested, but every call must be adjusted to use the ExpAsset.