Updatepresolve

[pkofod]

Fixes #222 at the expense of a few more calculations each time solve is called. Advanced users can easily create a MyIndShkType and overwrite preSolve with a new 3-line method that doesn't update between solve() calls. The cost is probably negligible anyway, compared to solving the model and any post-processing you might do after solving a model.

[mnwhite]

This has been one of the long-demanded items (as a one line fix). Gentle intro notebook should be updated to reflect this change. That's part of my notebook overhaul.

…

On Thu, Jun 20, 2019, 6:09 AM Patrick Kofod Mogensen < ***@***.***> wrote: Fixes #222 <#222> at the expense of a few more calculations each time solve is called. Advanced users can easily create a MyIndShkType and overwrite preSolve with a new 3-line method that doesn't update between solve() calls. The cost is probably negligible anyway, compared to solving the model and any post-processing you might do after solving a model. ------------------------------ You can view, comment on, or merge this pull request online at: #323 Commit Summary - Add self.update() to self.preSolve in IndShockConsumerType to facilitate users changing attributes between construction and solve(). - Fix conflicts when merging with master. File Changes - *M* HARK/ConsumptionSaving/ConsIndShockModel.py <https://github.com/econ-ark/HARK/pull/323/files#diff-0> (3) Patch Links: - https://github.com/econ-ark/HARK/pull/323.patch - https://github.com/econ-ark/HARK/pull/323.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#323?email_source=notifications&email_token=ADKRAFLJ2GZKBFW5WIDKY7TP3NJNLA5CNFSM4HZRMFJKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G2VEWVQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADKRAFN42QWNNT4XRBUJDQDP3NJNLANCNFSM4HZRMFJA> .

[pkofod]

This has been one of the long-demanded items (as a one line fix). Gentle intro notebook should be updated to reflect this change. That's part of my notebook overhaul.

Just verifying: you agree that this should be done and it should be done like this, right?

[mnwhite]

Yes, please.

…

On Thu, Jun 20, 2019, 4:18 PM Patrick Kofod Mogensen < ***@***.***> wrote: This has been one of the long-demanded items (as a one line fix). Gentle intro notebook should be updated to reflect this change. That's part of my notebook overhaul. Just verifying: you agree that this should be done and it should be done like this, right? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#323?email_source=notifications&email_token=ADKRAFLWRNWJLCCFPLKW3RTP3PQYTA5CNFSM4HZRMFJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYGP2CI#issuecomment-504167689>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADKRAFILQI6SRM74OV3JK6LP3PQYTANCNFSM4HZRMFJA> .

[pkofod]

Great. Merge when you're ready :)

[llorracc]

Ultimately, we will want to define a distribution object which "stores" the parameters needed to produce its approximation (like, that it is a lognormal with mean 0.02 and standard deviation of 0.1 produced by the equiprobable method of approximation using seven nodes). That way, the current parameters can be compared to the stored one, and the distribution computed only if it has changed. A quicker but uglier fix would be just to have the agent object store this info (instead of having a separate distribution object for it).

@albop

[pkofod]

Ultimately, we will want to define a distribution object which "stores" the parameters needed to produce its approximation (like, that it is a lognormal with mean 0.02 and standard deviation of 0.1 produced by the equiprobable method of approximation using seven nodes). That way, the current parameters can be compared to the stored one, and the distribution computed only if it has changed. A quicker but uglier fix would be just to have the agent object store this info (instead of having a separate distribution object for it).

I agree that it could be done to make this slightly more efficient, but I'm wondering if the extra complexity is really worth it? I have strong doubts that re-calculating these things will be significant in the overall picture. We can try a specific implementation at some point to see if the extra complexity is worth it.

[shaunagm]

@pkofod Can you write a release note? Thanks.

[pkofod]

Uhm yes. Something like.

"Added a call to updateIncomeProcess() in preSolve() to avoid solutions being based on wrong income process specifications if some parameters change between two solve() calls."