# ExpAssets make impossible possible for StationaryDistributions
**URL:** https://discourse.vfitoolkit.com/t/expassets-make-impossible-possible-for-stationarydistributions/684
**Category:** Uncategorized
**Created:** [July 3, 2026, 4:52am UTC](https://discourse.vfitoolkit.com/t/expassets-make-impossible-possible-for-stationarydistributions/684 "2026-07-03T04:52:05Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@MichaelTiemann](https://discourse.vfitoolkit.com/u/MichaelTiemann)
#### Post date: [July 3, 2026, 4:52am UTC](https://discourse.vfitoolkit.com/t/expassets-make-impossible-possible-for-stationarydistributions/684/1 "2026-07-03T04:52:06Z")
I observed strange behavior in my modified LifeCycleModel21 after adding an Experience Asset.
I observed that the Value Function was as I expected: `-Inf` when `ageJ>=Jr` and the agent tried to carry or take on debt. My asset grid has a zero value at index 21, so I can easily spot negative assets in the first 20 rows. After computing the Stationary Distribution, I observed
```auto
K>> squeeze(StationaryDist_med_only(:,1,1:10,1,1,81))
ans =
83×10 gpuArray single matrix
1.0e-07 *
0.0809 0.0872 0.0981 0.0798 0.0411 0.0167 0.0060 0.0021 0.0007 0.0002
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0.0939 0.0000 0.0002 0.0030 0.0125 0 0 0 0 0
0.2088 0.0213 0.0017 0.0006 0 0 0 0 0 0
0.2792 0.0029 0.0654 0.3099 0 0 0 0 0 0
0.1300 0.2895 0.7453 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
```
Note the non-zero entries on row 1 (which are incorrect…that’s the maximum debt level) and rows 21-24, which are rows with asset values at or greater than zero.
In my case, `StationaryDist_FHorz_Case1` dispatches down to `StationaryDist_FHorz_ExpAssetz` which gives correct information as far as locating the aprime value of the experience asset on the grid (using grid probabilities). But what this function cannot do is to ascertain whether or not the aprime in question is valid from the perspective of the overall return function. As a result, the values it returns sprinkle possibilities that exist in the Experience Asset’s aprime state space into the overali state space where they are forbidden.
Here’s how I have corrected it, ex post facto in my own code:
```auto
StationaryDist_med_only=StationaryDist_FHorz_Case1(jequaloneDist_med_only,AgeWeightsParamNames,Policy_med_only,n_d,n_a,n_z,N_j,pi_z_med_only_J,Params,simoptions_med_only);
StationaryDist_med_only(isinf(V_med_only))=0; % If the ReturnFn forbids it, it is forbidden
```
I think it would be cleaner of the Stationary Distribution returned a correct value in the first place, not one that needs to be corrected. One possible solution is to forbid Experience Assets from being able to move a policy state from `1` to another value. I.e., in order for the Experience Asset to contribute to the action, it must be in a non-1 state. I leave it to the author to make the call as to what’s the right fix.
---
### Author:  [@MichaelTiemann](https://discourse.vfitoolkit.com/u/MichaelTiemann)
#### Post date: [July 4, 2026, 8:14am UTC](https://discourse.vfitoolkit.com/t/expassets-make-impossible-possible-for-stationarydistributions/684/2 "2026-07-04T08:14:47Z")
The plot thickens…
I found a problem with Experience Asset value calculations ([All Vlower/Vupper compositions need a NaN check · Issue #111 · vfitoolkit/VFIToolkit-matlab · GitHub](https://github.com/vfitoolkit/VFIToolkit-matlab/issues/111)) and after implementing what I thought would be a fix, I found that in some cases (not all), the proposed fix here wipes out all the values in my Stationary Distribution, leading to an attempt to divide by zero (around line 482 of `LifeCycleProfiles_FHorz_Case1`:
```auto
StationaryDistVec_kk=StationaryDistVec_kk./sum(StationaryDistVec_kk); % Normalize to sum to one for this 'agegrouping'
```
It is entirely possible that the observed problem in this report is resolved more properly via the resolution of Issue #111. In which case I can delete this thread as noise, as I no longer observe the ghosts lurking where they do not belong.