Bug fix to drawDiscrete

[edmundcrawley]

These two lines can be run outside the loop, avoiding an error when N<events.size and also saving time.
The error occurs when j=0 and event_draws is empty (X[event_draws] throws an error).

[sbenthall]

This is a good catch.

I wonder why the ConsAggShockModel is using the exact_match in the solver.
This is not standard across the library.

That question should not block this PR though, which is great.
The test is failing because of the difference in random number generation.
If you could push a commit that changes the value in the assert statement so it passes, that would do.

[mnwhite]

It's using exact_match to try to reduce spurious aggregate variance arising from the aggregation of a finite number of idiosyncratic shocks. HA-DSGE models usually/always posit that there is a continuum of households, so in the "true model" every household would have its "shadow household" with a history of idiosyncratic shocks that is the exact opposite (in some sense) of the one that it experienced. The volatility of aggregate quantities should arise through actual aggregate shocks, not finite samples of idiosyncratic shocks (but the nature of those dynamics can depend on the distribution of idiosyncratic states). In numeric practice, we're simulating a finite number of households, usually on the order of 10,000 to 100,000-- a far cry from infinity. This is not a large enough number for idiosyncratic shocks to all "cancel out", so aggregate dynamics can depend on idiosyncratic realizations. This is exacerbated by the realistic income process in our models, which generates a *wide* distribution of permanent income; the idiosyncratic shocks that happen to *some* households matter more than others for the aggregate. Using exact_match at least fixes this problem in the aggregate, so that mean(TranShk) = mean(PermShk) = 1 in *every* period. This is a variation of drawing random numbers from a (log) symmetric distribution using "antithetic nodes". In legacy Mathematica code, Chris has a couple other tricks like this, including methods for selecting who dies and (I think) who gets which idiosyncratic shock. Somewhere in ConsAggShockModel you can find commented out code where I implemented the first, but found that it caused more problems in estimating a model than it solved when solving the model at particular parameter values.

…

On Wed, Jun 17, 2020 at 1:49 PM Sebastian Benthall ***@***.***> wrote: This is a good catch. I wonder why the ConsAggShockModel is using the exact_match in the solver. This is not standard across the library. That question should not block this PR though, which is great. The test is failing because of the difference in random number generation. If you could push a commit that changes the value in the assert statement so it passes, that would do. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFITHM3IIGBPWMAGRNDRXD633ANCNFSM4OAY737Q> .

[sbenthall]

Thanks for explaining that, Matt.
I see now why exact_match is used here.

I'm less clear why it is used here, and not in other places.
It would be nice if there were a consistent, documented interface for choosing it, especially if it matters for the interpretation of the output.