Constrained perfect foresight

Add liquidity constraint (BoroCnstArt) to the perfect foresight consumption-saving model.  Doesn't calculate value function if BoroCnstArt is not None, as we don't have the property that vNvrsFunc is piecewise linear.  True value function requires calculating value at a bunch of points and then constructing as usual.  This would be additional computation (and would require more parameters), so I didn't write this bit.

Okay, automated testing is pretty cool.  It alerted me to a (stupid) typo I made at the last minute by failing to manually test a case.

Even cooler: It flagged something that works in Py2 but not Py3.  Very neat.

The model notebook in DEMARK has been updated to account for this change (in a PR), but it should only be merged once this PR is merged and we do a release.  Our DEMARKs are pointing to the latest public release of HARK, correct?

Good question.  It was not.  I've now updated reqirements.txt.  Also
noticed that postBuild.bat did not have the automatic connection to the
Zotero database that was there for the unix postBuild so I've added it to
the bat file.  Can you test whether it works?
On Sun, Jun 2, 2019 at 4:17 PM Matthew N. White<EMAIL_ADDRESS>wrote:

The model notebook in DEMARK has been updated to account for this change
(in a PR), but it should only be merged once this PR is merged and we
do a release. Our DEMARKs are pointing to the latest public release of
HARK, correct?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK7Z2ALUI527OFONEQCDPYQTEXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX5FGY#issuecomment-498061979,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCK74UQUXKZHYSJ4HZEVLPYQTEXANCNFSM4HRRZV2A
.

--

Chris Carroll

Just looked through the code -- it looks good (though haven't tested until we resolve whether this should be a "breaking change".  I don't want to do the thing of including a custom version of ConsIndShockModel.py in a notebook until we make the new release.
But one question:  Don't see why the aXtraGrid parameter is necessary.  The extra gridpoints are constructed on the fly, and there'll be one of them added for each iteration, so the user doesn't need to specify that number in advance, just needs to specify how many periods back to solve, right?  In fact, if aXtraGrid is fixed and they specify that the problem should be solved one more period, there's no way to do that without adding more gridpoints?

You can't specify how many periods back to solve if it's an infinite
horizon model-- it solves until the cFunc converges.  If you try to run an
infinite horizon model with a borrowing constraint and aXtraCount set to
None, then the solver will repeatedly add one more kink, over and over
again.  The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way an array
of size 258 and an array of size 259 can be "close"!  Eventually, the top
gridpoint becomes so high that there's an overflow error and the solution
collapses.
So we need to either specify a maximum amount of gridpoints or a highest
value (relative to the lowest value).  I sense that you're going to suggest
that we change the distance criterion to mNrmSS, but that would have very
bad effects in the perfect foresight model.  The consumption function is
essentially constructed from "bottom upward" in the PF model, so mNrmSS
will very quickly return the same value on successive iterations... but the
consumption function above it is way off from the correct solution.
Note that you don't need to put this custom version into a notebook to test
it.  Just use developer mode on your computer and change your branch to
mine.  If your (locally run) notebook imports HARK, then it will use my
version!
 -- mnw

On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though haven't tested until
we resolve whether this should be a "breaking change". I don't want to do
the thing of including a custom version of ConsIndShockModel.py in a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is necessary. The
extra gridpoints are constructed on the fly, and there'll be one of them
added for each iteration, so the user doesn't need to specify that number
in advance, just needs to specify how many periods back to solve, right? In
fact, if aXtraGrid is fixed and they specify that the problem should be
solved one more period, there's no way to do that without adding more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
.

Realized I never responded to this.  I'll try to test it at some point; I
know I had to do some of the installation steps "by hand" because they
didn't work right in postBuild.
On Sun, Jun 2, 2019 at 5:59 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Good question. It was not. I've now updated reqirements.txt. Also
noticed that postBuild.bat did not have the automatic connection to the
Zotero database that was there for the unix postBuild so I've added it to
the bat file. Can you test whether it works?
On Sun, Jun 2, 2019 at 4:17 PM Matthew N. White<EMAIL_ADDRESS>wrote:

The model notebook in DEMARK has been updated to account for this change
(in a PR), but it should only be merged once this PR is merged and we
do a release. Our DEMARKs are pointing to the latest public release of
HARK, correct?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK7Z2ALUI527OFONEQCDPYQTEXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX5FGY#issuecomment-498061979
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAKCK74UQUXKZHYSJ4HZEVLPYQTEXANCNFSM4HRRZV2A
.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFONF7ROO4G2UWIDHGDPYQ7BDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX626Q#issuecomment-498068858,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFO6TN36SDMG5U6OYALPYQ7BDANCNFSM4HRRZV2A
.

"until the cFunc converges" requires some convergence criterion.  If that
criterion includes the MPC $c^{\prime(m))$, there IS no interval over which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the question is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points (corresponding to
future constraints) at which the right and left derivatives are different.
(Kink points).
  (That is, we should not go out of our way
to try to accommodate them).
PS.  People remember Karl Weierstrass for his finding that any function
which "is" continuously differentiable (to arbitrarily many derivatives)
over an interval can be (in the limit) represented with arbitrary accuracy
by polynomials (I think that's the gist of his theorem).  I like him better
for pointing out the existence of functions that CANNOT be represented
that way .
Even if it is true that the limits of the left and right derivatives
converge at every point, for any finite number of periods they are finitely
different for a finite number of points, which is an abomination (from the
standpoint of people who want to stably represent functions in discrete
terms like those that computers can easily handle).  At those points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion for the
LEVEL of $c$ that (say) should apply at every gridpoint, or they should
supply a number of periods backwards (otherwise they should be required to
define their own convergence criterion).  But if they are supplying the
'level' criterion there is no reason to require them also (redundantly) to
incorporate aExtraGrid.
PS.  (I'm also on the side of Kronecker, who said "God made the integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an infinite
horizon model-- it solves until the cFunc converges. If you try to run an
infinite horizon model with a borrowing constraint and aXtraCount set to
None, then the solver will repeatedly add one more kink, over and over
again.

Yay for it!  That's the right thing to do!

The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way an array
of size 258 and an array of size 259 can be "close"! Eventually, the top
gridpoint becomes so high that there's an overflow error and the solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints or a highest
value (relative to the lowest value). I sense that you're going to suggest
that we change the distance criterion to mNrmSS, but that would have very
bad effects in the perfect foresight model. The consumption function is
essentially constructed from "bottom upward" in the PF model, so mNrmSS
will very quickly return the same value on successive iterations... but the
consumption function above it is way off from the correct solution.
Note that you don't need to put this custom version into a notebook to test
it. Just use developer mode on your computer and change your branch to
mine. If your (locally run) notebook imports HARK, then it will use my
version!

Yes, but I want to SHARE this notebook with referees/editors/the universe.
If I could impose a requirements "econ-ark==" whatever in which I could
guarantee it would work, then that might be enough.  To do that we'd need
to create a new dev branch (containing the breaking changes) which will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though haven't tested
until
we resolve whether this should be a "breaking change". I don't want to do
the thing of including a custom version of ConsIndShockModel.py in a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is necessary. The
extra gridpoints are constructed on the fly, and there'll be one of them
added for each iteration, so the user doesn't need to specify that number
in advance, just needs to specify how many periods back to solve, right?
In
fact, if aXtraGrid is fixed and they specify that the problem should be
solved one more period, there's no way to do that without adding more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
.

--

Chris Carroll

These "breaking changes" are incredibly minor. Fixing the problem merely
requires anyone using PerfForesightConsumerType to add BoroCnstArt and
aXtraCount to their dictionaries.    This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to aXtraMax,
where you specify a (very large) aNrm beyond which you would never possibly
care about the consumption function, like 2000.  Any kinks beyond that are
considered irrelevant.
 -- mnw

On Fri, Jun 7, 2019 at 11:21 PM llorracc-git<EMAIL_ADDRESS>wrote:

"until the cFunc converges" requires some convergence criterion. If that
criterion includes the MPC $c^{\prime(m))$, there IS no interval over which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the question is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points (corresponding to
future constraints) at which the right and left derivatives are different.
(Kink points).
 (That is, we should not go out of our way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any function
which "is" continuously differentiable (to arbitrarily many derivatives)
over an interval can be (in the limit) represented with arbitrary accuracy
by polynomials (I think that's the gist of his theorem). I like him better
for pointing out the existence of functions that CANNOT be represented
that way .
Even if it is true that the limits of the left and right derivatives
converge at every point, for any finite number of periods they are finitely
different for a finite number of points, which is an abomination (from the
standpoint of people who want to stably represent functions in discrete
terms like those that computers can easily handle). At those points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion for the
LEVEL of $c$ that (say) should apply at every gridpoint, or they should
supply a number of periods backwards (otherwise they should be required to
define their own convergence criterion). But if they are supplying the
'level' criterion there is no reason to require them also (redundantly) to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an infinite
horizon model-- it solves until the cFunc converges. If you try to run an
infinite horizon model with a borrowing constraint and aXtraCount set to
None, then the solver will repeatedly add one more kink, over and over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way an array
of size 258 and an array of size 259 can be "close"! Eventually, the top
gridpoint becomes so high that there's an overflow error and the solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints or a highest
value (relative to the lowest value). I sense that you're going to
suggest
that we change the distance criterion to mNrmSS, but that would have very
bad effects in the perfect foresight model. The consumption function is
essentially constructed from "bottom upward" in the PF model, so mNrmSS
will very quickly return the same value on successive iterations... but
the
consumption function above it is way off from the correct solution.
Note that you don't need to put this custom version into a notebook to
test
it. Just use developer mode on your computer and change your branch to
mine. If your (locally run) notebook imports HARK, then it will use my
version!

Yes, but I want to SHARE this notebook with referees/editors/the universe.
If I could impose a requirements "econ-ark==" whatever in which I could
guarantee it would work, then that might be enough. To do that we'd need
to create a new dev branch (containing the breaking changes) which will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though haven't tested
until
we resolve whether this should be a "breaking change". I don't want to
do
the thing of including a custom version of ConsIndShockModel.py in a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is necessary.
The
extra gridpoints are constructed on the fly, and there'll be one of
them
added for each iteration, so the user doesn't need to specify that
number
in advance, just needs to specify how many periods back to solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the problem should be
solved one more period, there's no way to do that without adding more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
.

If you prefer a different stopping condition, I can change it to aXtraMax,
where you specify a (very large) aNrm beyond which you would never possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.

I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that we want to
say that a function has converged if at every $m$ both $c(m)$ and $c'(m)$
converge.  But every extra iteration back adds another point at which
$c'(m)$ is undefined, so the function never converges in that sense.
So, I think the user of the constrained version of the solver function
should just be required to say how many periods from the end they want to
solve, and the number of gridpoints is periods+2.  Like, if they want to
solve zero periods back, we need only 2 gridpoints (to define the 45 degree
line).  If they want to solve 1 period, the function is piecewise linear
with two segments, so we need 3 gridpoints, and so on.  Does that make
sense?  If they want to define some convergence criterion themselves, they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able to make a
DemARK notebook to illustrate some of this as a companion to the LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White<EMAIL_ADDRESS>wrote:

These "breaking changes" are incredibly minor. Fixing the problem merely
requires anyone using PerfForesightConsumerType to add BoroCnstArt and
aXtraCount to their dictionaries.  This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to aXtraMax,
where you specify a (very large) aNrm beyond which you would never possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git<EMAIL_ADDRESS>wrote:

"until the cFunc converges" requires some convergence criterion. If that
criterion includes the MPC $c^{\prime(m))$, there IS no interval over
which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the question is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points (corresponding
to
future constraints) at which the right and left derivatives are
different.
(Kink points).
 (That is, we should not go out of our
way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any function
which "is" continuously differentiable (to arbitrarily many derivatives)
over an interval can be (in the limit) represented with arbitrary
accuracy
by polynomials (I think that's the gist of his theorem). I like him
better
for pointing out the existence of functions that CANNOT be represented
that way .
Even if it is true that the limits of the left and right derivatives
converge at every point, for any finite number of periods they are
finitely
different for a finite number of points, which is an abomination (from
the
standpoint of people who want to stably represent functions in discrete
terms like those that computers can easily handle). At those points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion for the
LEVEL of $c$ that (say) should apply at every gridpoint, or they should
supply a number of periods backwards (otherwise they should be required
to
define their own convergence criterion). But if they are supplying the
'level' criterion there is no reason to require them also (redundantly)
to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an infinite
horizon model-- it solves until the cFunc converges. If you try to run
an
infinite horizon model with a borrowing constraint and aXtraCount set
to
None, then the solver will repeatedly add one more kink, over and over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way an
array
of size 258 and an array of size 259 can be "close"! Eventually, the
top
gridpoint becomes so high that there's an overflow error and the
solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints or a
highest
value (relative to the lowest value). I sense that you're going to
suggest
that we change the distance criterion to mNrmSS, but that would have
very
bad effects in the perfect foresight model. The consumption function is
essentially constructed from "bottom upward" in the PF model, so mNrmSS
will very quickly return the same value on successive iterations... but
the
consumption function above it is way off from the correct solution.
Note that you don't need to put this custom version into a notebook to
test
it. Just use developer mode on your computer and change your branch to
mine. If your (locally run) notebook imports HARK, then it will use my
version!

Yes, but I want to SHARE this notebook with referees/editors/the
universe.
If I could impose a requirements "econ-ark==" whatever in which I could
guarantee it would work, then that might be enough. To do that we'd need
to create a new dev branch (containing the breaking changes) which will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though haven't tested
until
we resolve whether this should be a "breaking change". I don't want
to
do
the thing of including a custom version of ConsIndShockModel.py in a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is necessary.
The
extra gridpoints are constructed on the fly, and there'll be one of
them
added for each iteration, so the user doesn't need to specify that
number
in advance, just needs to specify how many periods back to solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the problem should
be
solved one more period, there's no way to do that without adding more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
.

--

Chris Carroll

That's essentially what aXtraCount does; I just used that variable name to
be like the other models.  You're specifying how many periods worth of
kinks to care about, and throwing out everything beyond that.  That's what
generates "convergence".
 -- mnw

On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.

I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that we want to
say that a function has converged if at every $m$ both $c(m)$ and $c'(m)$
converge. But every extra iteration back adds another point at which
$c'(m)$ is undefined, so the function never converges in that sense.
So, I think the user of the constrained version of the solver function
should just be required to say how many periods from the end they want to
solve, and the number of gridpoints is periods+2. Like, if they want to
solve zero periods back, we need only 2 gridpoints (to define the 45 degree
line). If they want to solve 1 period, the function is piecewise linear
with two segments, so we need 3 gridpoints, and so on. Does that make
sense? If they want to define some convergence criterion themselves, they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able to make a
DemARK notebook to illustrate some of this as a companion to the LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White<EMAIL_ADDRESS>
wrote:

These "breaking changes" are incredibly minor. Fixing the problem merely
requires anyone using PerfForesightConsumerType to add BoroCnstArt and
aXtraCount to their dictionaries.  This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never
possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git<EMAIL_ADDRESS>wrote:

"until the cFunc converges" requires some convergence criterion. If
that
criterion includes the MPC $c^{\prime(m))$, there IS no interval over
which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the question
is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points (corresponding
to
future constraints) at which the right and left derivatives are
different.
(Kink points).
 (That is, we should not go out of our
way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any function
which "is" continuously differentiable (to arbitrarily many
derivatives)
over an interval can be (in the limit) represented with arbitrary
accuracy
by polynomials (I think that's the gist of his theorem). I like him
better
for pointing out the existence of functions that CANNOT be represented
that way .
Even if it is true that the limits of the left and right derivatives
converge at every point, for any finite number of periods they are
finitely
different for a finite number of points, which is an abomination (from
the
standpoint of people who want to stably represent functions in discrete
terms like those that computers can easily handle). At those points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion for
the
LEVEL of $c$ that (say) should apply at every gridpoint, or they should
supply a number of periods backwards (otherwise they should be required
to
define their own convergence criterion). But if they are supplying the
'level' criterion there is no reason to require them also (redundantly)
to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the
integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an infinite
horizon model-- it solves until the cFunc converges. If you try to
run
an
infinite horizon model with a borrowing constraint and aXtraCount set
to
None, then the solver will repeatedly add one more kink, over and
over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way an
array
of size 258 and an array of size 259 can be "close"! Eventually, the
top
gridpoint becomes so high that there's an overflow error and the
solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints or a
highest
value (relative to the lowest value). I sense that you're going to
suggest
that we change the distance criterion to mNrmSS, but that would have
very
bad effects in the perfect foresight model. The consumption function
is
essentially constructed from "bottom upward" in the PF model, so
mNrmSS
will very quickly return the same value on successive iterations...
but
the
consumption function above it is way off from the correct solution.
Note that you don't need to put this custom version into a notebook
to
test
it. Just use developer mode on your computer and change your branch
to
mine. If your (locally run) notebook imports HARK, then it will use
my
version!

Yes, but I want to SHARE this notebook with referees/editors/the
universe.
If I could impose a requirements "econ-ark==" whatever in which I could
guarantee it would work, then that might be enough. To do that we'd
need
to create a new dev branch (containing the breaking changes) which will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though haven't
tested
until
we resolve whether this should be a "breaking change". I don't want
to
do
the thing of including a custom version of ConsIndShockModel.py in
a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is
necessary.
The
extra gridpoints are constructed on the fly, and there'll be one of
them
added for each iteration, so the user doesn't need to specify that
number
in advance, just needs to specify how many periods back to solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the problem
should
be
solved one more period, there's no way to do that without adding
more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A
.

I see, so we are on the same page.  But, I'm afraid that calling it
aXtraGrid might be confusing to users.  Could we call it something else,
like "NumCnstPrds" or something like that?
PS.  I take it that the terminal function is $c=m$?  An alternative would
be for the terminal function to be the unconstrained analytical solution.
On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White<EMAIL_ADDRESS>wrote:

That's essentially what aXtraCount does; I just used that variable name to
be like the other models. You're specifying how many periods worth of
kinks to care about, and throwing out everything beyond that. That's what
generates "convergence".
-- mnw
On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never
possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.

I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that we want
to
say that a function has converged if at every $m$ both $c(m)$ and $c'(m)$
converge. But every extra iteration back adds another point at which
$c'(m)$ is undefined, so the function never converges in that sense.
So, I think the user of the constrained version of the solver function
should just be required to say how many periods from the end they want to
solve, and the number of gridpoints is periods+2. Like, if they want to
solve zero periods back, we need only 2 gridpoints (to define the 45
degree
line). If they want to solve 1 period, the function is piecewise linear
with two segments, so we need 3 gridpoints, and so on. Does that make
sense? If they want to define some convergence criterion themselves, they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able to make
a
DemARK notebook to illustrate some of this as a companion to the
LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

These "breaking changes" are incredibly minor. Fixing the problem
merely
requires anyone using PerfForesightConsumerType to add BoroCnstArt and
aXtraCount to their dictionaries.  This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never
possibly
care about the consumption function, like 2000. Any kinks beyond that
are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git<EMAIL_ADDRESS>

wrote:

"until the cFunc converges" requires some convergence criterion. If
that
criterion includes the MPC $c^{\prime(m))$, there IS no interval over
which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the
question
is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points
(corresponding
to
future constraints) at which the right and left derivatives are
different.
(Kink points).
 (That is, we should not go out of
our
way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any
function
which "is" continuously differentiable (to arbitrarily many
derivatives)
over an interval can be (in the limit) represented with arbitrary
accuracy
by polynomials (I think that's the gist of his theorem). I like him
better
for pointing out the existence of functions that CANNOT be
represented
that way .
Even if it is true that the limits of the left and right derivatives
converge at every point, for any finite number of periods they are
finitely
different for a finite number of points, which is an abomination
(from
the
standpoint of people who want to stably represent functions in
discrete
terms like those that computers can easily handle). At those points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion for
the
LEVEL of $c$ that (say) should apply at every gridpoint, or they
should
supply a number of periods backwards (otherwise they should be
required
to
define their own convergence criterion). But if they are supplying
the
'level' criterion there is no reason to require them also
(redundantly)
to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the
integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an
infinite
horizon model-- it solves until the cFunc converges. If you try to
run
an
infinite horizon model with a borrowing constraint and aXtraCount
set
to
None, then the solver will repeatedly add one more kink, over and
over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way an
array
of size 258 and an array of size 259 can be "close"! Eventually,
the
top
gridpoint becomes so high that there's an overflow error and the
solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints or a
highest
value (relative to the lowest value). I sense that you're going to
suggest
that we change the distance criterion to mNrmSS, but that would
have
very
bad effects in the perfect foresight model. The consumption
function
is
essentially constructed from "bottom upward" in the PF model, so
mNrmSS
will very quickly return the same value on successive iterations...
but
the
consumption function above it is way off from the correct
solution.
Note that you don't need to put this custom version into a notebook
to
test
it. Just use developer mode on your computer and change your branch
to
mine. If your (locally run) notebook imports HARK, then it will use
my
version!

Yes, but I want to SHARE this notebook with referees/editors/the
universe.
If I could impose a requirements "econ-ark==" whatever in which I
could
guarantee it would work, then that might be enough. To do that we'd
need
to create a new dev branch (containing the breaking changes) which
will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though haven't
tested
until
we resolve whether this should be a "breaking change". I don't
want
to
do
the thing of including a custom version of ConsIndShockModel.py
in
a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is
necessary.
The
extra gridpoints are constructed on the fly, and there'll be one
of
them
added for each iteration, so the user doesn't need to specify
that
number
in advance, just needs to specify how many periods back to solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the problem
should
be
solved one more period, there's no way to do that without adding
more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A
.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A
.

--

Chris Carroll

It's called aXtraCount, not aXtraGrid.  We can call it anything you want,
but if we're going to use a new variable name, I'd prefer to be direct,
with MaxKinks or something like that.
The terminal period solution is c=m, yes.  Making making the terminal
period solver "more clever" is a different topic entirely, and would take
real effort/thought/work.  If you want this ready to use on your project,
this is not something you should be asking for now.
 -- mnw

On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

I see, so we are on the same page. But, I'm afraid that calling it
aXtraGrid might be confusing to users. Could we call it something else,
like "NumCnstPrds" or something like that?
PS. I take it that the terminal function is $c=m$? An alternative would
be for the terminal function to be the unconstrained analytical solution.
On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White<EMAIL_ADDRESS>
wrote:

That's essentially what aXtraCount does; I just used that variable name
to
be like the other models. You're specifying how many periods worth of
kinks to care about, and throwing out everything beyond that. That's what
generates "convergence".
-- mnw
On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never
possibly
care about the consumption function, like 2000. Any kinks beyond that
are
considered irrelevant.

I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that we
want
to
say that a function has converged if at every $m$ both $c(m)$ and
$c'(m)$
converge. But every extra iteration back adds another point at which
$c'(m)$ is undefined, so the function never converges in that sense.
So, I think the user of the constrained version of the solver function
should just be required to say how many periods from the end they want
to
solve, and the number of gridpoints is periods+2. Like, if they want to
solve zero periods back, we need only 2 gridpoints (to define the 45
degree
line). If they want to solve 1 period, the function is piecewise linear
with two segments, so we need 3 gridpoints, and so on. Does that make
sense? If they want to define some convergence criterion themselves,
they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able to
make
a
DemARK notebook to illustrate some of this as a companion to the
LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

These "breaking changes" are incredibly minor. Fixing the problem
merely
requires anyone using PerfForesightConsumerType to add BoroCnstArt
and
aXtraCount to their dictionaries.  This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never
possibly
care about the consumption function, like 2000. Any kinks beyond that
are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
<EMAIL_ADDRESS>

wrote:

"until the cFunc converges" requires some convergence criterion. If
that
criterion includes the MPC $c^{\prime(m))$, there IS no interval
over
which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the
question
is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points
(corresponding
to
future constraints) at which the right and left derivatives are
different.
(Kink points).
 (That is, we should not go out of
our
way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any
function
which "is" continuously differentiable (to arbitrarily many
derivatives)
over an interval can be (in the limit) represented with arbitrary
accuracy
by polynomials (I think that's the gist of his theorem). I like him
better
for pointing out the existence of functions that CANNOT be
represented
that way .
Even if it is true that the limits of the left and right
derivatives
converge at every point, for any finite number of periods they are
finitely
different for a finite number of points, which is an abomination
(from
the
standpoint of people who want to stably represent functions in
discrete
terms like those that computers can easily handle). At those
points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion
for
the
LEVEL of $c$ that (say) should apply at every gridpoint, or they
should
supply a number of periods backwards (otherwise they should be
required
to
define their own convergence criterion). But if they are supplying
the
'level' criterion there is no reason to require them also
(redundantly)
to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the
integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an
infinite
horizon model-- it solves until the cFunc converges. If you try
to
run
an
infinite horizon model with a borrowing constraint and aXtraCount
set
to
None, then the solver will repeatedly add one more kink, over and
over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way
an
array
of size 258 and an array of size 259 can be "close"! Eventually,
the
top
gridpoint becomes so high that there's an overflow error and the
solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints or a
highest
value (relative to the lowest value). I sense that you're going
to
suggest
that we change the distance criterion to mNrmSS, but that would
have
very
bad effects in the perfect foresight model. The consumption
function
is
essentially constructed from "bottom upward" in the PF model, so
mNrmSS
will very quickly return the same value on successive
iterations...
but
the
consumption function above it is way off from the correct
solution.
Note that you don't need to put this custom version into a
notebook
to
test
it. Just use developer mode on your computer and change your
branch
to
mine. If your (locally run) notebook imports HARK, then it will
use
my
version!

Yes, but I want to SHARE this notebook with referees/editors/the
universe.
If I could impose a requirements "econ-ark==" whatever in which I
could
guarantee it would work, then that might be enough. To do that we'd
need
to create a new dev branch (containing the breaking changes) which
will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though haven't
tested
until
we resolve whether this should be a "breaking change". I don't
want
to
do
the thing of including a custom version of ConsIndShockModel.py
in
a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is
necessary.
The
extra gridpoints are constructed on the fly, and there'll be
one
of
them
added for each iteration, so the user doesn't need to specify
that
number
in advance, just needs to specify how many periods back to
solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the problem
should
be
solved one more period, there's no way to do that without
adding
more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A
.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A
.

MaxKinks is fine.  Or MaxPrds.
I wasn't asking to add a new terminal function, just asking what it was.
It's not worth either of our time to add that option.
On Sat, Jun 8, 2019 at 11:25 AM Matthew N. White<EMAIL_ADDRESS>wrote:

It's called aXtraCount, not aXtraGrid. We can call it anything you want,
but if we're going to use a new variable name, I'd prefer to be direct,
with MaxKinks or something like that.
The terminal period solution is c=m, yes. Making making the terminal
period solver "more clever" is a different topic entirely, and would take
real effort/thought/work. If you want this ready to use on your project,
this is not something you should be asking for now.
-- mnw
On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

I see, so we are on the same page. But, I'm afraid that calling it
aXtraGrid might be confusing to users. Could we call it something else,
like "NumCnstPrds" or something like that?
PS. I take it that the terminal function is $c=m$? An alternative would
be for the terminal function to be the unconstrained analytical solution.
On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

That's essentially what aXtraCount does; I just used that variable name
to
be like the other models. You're specifying how many periods worth of
kinks to care about, and throwing out everything beyond that. That's
what
generates "convergence".
-- mnw
On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never
possibly
care about the consumption function, like 2000. Any kinks beyond that
are
considered irrelevant.

I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that we
want
to
say that a function has converged if at every $m$ both $c(m)$ and
$c'(m)$
converge. But every extra iteration back adds another point at which
$c'(m)$ is undefined, so the function never converges in that sense.
So, I think the user of the constrained version of the solver
function
should just be required to say how many periods from the end they
want
to
solve, and the number of gridpoints is periods+2. Like, if they want
to
solve zero periods back, we need only 2 gridpoints (to define the 45
degree
line). If they want to solve 1 period, the function is piecewise
linear
with two segments, so we need 3 gridpoints, and so on. Does that make
sense? If they want to define some convergence criterion themselves,
they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able to
make
a
DemARK notebook to illustrate some of this as a companion to the
LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

These "breaking changes" are incredibly minor. Fixing the problem
merely
requires anyone using PerfForesightConsumerType to add BoroCnstArt
and
aXtraCount to their dictionaries.  This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never
possibly
care about the consumption function, like 2000. Any kinks beyond
that
are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
<EMAIL_ADDRESS>

wrote:

"until the cFunc converges" requires some convergence criterion.
If
that
criterion includes the MPC $c^{\prime(m))$, there IS no interval
over
which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the
question
is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points
(corresponding
to
future constraints) at which the right and left derivatives are
different.
(Kink points).
 (That is, we should not go out
of
our
way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any
function
which "is" continuously differentiable (to arbitrarily many
derivatives)
over an interval can be (in the limit) represented with arbitrary
accuracy
by polynomials (I think that's the gist of his theorem). I like
him
better
for pointing out the existence of functions that CANNOT be
represented
that way .
Even if it is true that the limits of the left and right
derivatives
converge at every point, for any finite number of periods they
are
finitely
different for a finite number of points, which is an abomination
(from
the
standpoint of people who want to stably represent functions in
discrete
terms like those that computers can easily handle). At those
points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion
for
the
LEVEL of $c$ that (say) should apply at every gridpoint, or they
should
supply a number of periods backwards (otherwise they should be
required
to
define their own convergence criterion). But if they are
supplying
the
'level' criterion there is no reason to require them also
(redundantly)
to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the
integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an
infinite
horizon model-- it solves until the cFunc converges. If you try
to
run
an
infinite horizon model with a borrowing constraint and
aXtraCount
set
to
None, then the solver will repeatedly add one more kink, over
and
over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no
way
an
array
of size 258 and an array of size 259 can be "close"!
Eventually,
the
top
gridpoint becomes so high that there's an overflow error and
the
solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints or
a
highest
value (relative to the lowest value). I sense that you're going
to
suggest
that we change the distance criterion to mNrmSS, but that would
have
very
bad effects in the perfect foresight model. The consumption
function
is
essentially constructed from "bottom upward" in the PF model,
so
mNrmSS
will very quickly return the same value on successive
iterations...
but
the
consumption function above it is way off from the correct
solution.
Note that you don't need to put this custom version into a
notebook
to
test
it. Just use developer mode on your computer and change your
branch
to
mine. If your (locally run) notebook imports HARK, then it will
use
my
version!

Yes, but I want to SHARE this notebook with referees/editors/the
universe.
If I could impose a requirements "econ-ark==" whatever in which I
could
guarantee it would work, then that might be enough. To do that
we'd
need
to create a new dev branch (containing the breaking changes)
which
will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though haven't
tested
until
we resolve whether this should be a "breaking change". I
don't
want
to
do
the thing of including a custom version of
ConsIndShockModel.py
in
a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is
necessary.
The
extra gridpoints are constructed on the fly, and there'll be
one
of
them
added for each iteration, so the user doesn't need to specify
that
number
in advance, just needs to specify how many periods back to
solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the problem
should
be
solved one more period, there's no way to do that without
adding
more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this
thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A
.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK734ZZHHQIC6UJSN3BDPZPFPHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWVZQ#issuecomment-500132582,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCK722RM5A7E4QLKJ4HNLPZPFPHANCNFSM4HRRZV2A
.

--

Chris Carroll

Adding that capability has been on my backburner for a while.  It's always
felt a little weird that the (unconstrained) perfect foresight model can
take longer to solve than the income shocks model... merely because it
takes so many periods for human wealth to converge, and thus for the linear
cFunc to stop "backing up"!  I'd like for the terminal period solver to
check whether it's an infinite horizon model, in which case it will use the
unconstrained perfect foresight solution as its initial guess (in both
PerfForesight and ConsIndShock).  That will make the PF model "converge" in
just 1 or 2 periods (I think HARK ignores the convergence check on the
first pass).
On Sat, Jun 8, 2019 at 11:37 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

MaxKinks is fine. Or MaxPrds.
I wasn't asking to add a new terminal function, just asking what it was.
It's not worth either of our time to add that option.
On Sat, Jun 8, 2019 at 11:25 AM Matthew N. White<EMAIL_ADDRESS>
wrote:

It's called aXtraCount, not aXtraGrid. We can call it anything you want,
but if we're going to use a new variable name, I'd prefer to be direct,
with MaxKinks or something like that.
The terminal period solution is c=m, yes. Making making the terminal
period solver "more clever" is a different topic entirely, and would take
real effort/thought/work. If you want this ready to use on your project,
this is not something you should be asking for now.
-- mnw
On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

I see, so we are on the same page. But, I'm afraid that calling it
aXtraGrid might be confusing to users. Could we call it something else,
like "NumCnstPrds" or something like that?
PS. I take it that the terminal function is $c=m$? An alternative would
be for the terminal function to be the unconstrained analytical
solution.
On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

That's essentially what aXtraCount does; I just used that variable
name
to
be like the other models. You're specifying how many periods worth of
kinks to care about, and throwing out everything beyond that. That's
what
generates "convergence".
-- mnw
On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never
possibly
care about the consumption function, like 2000. Any kinks beyond
that
are
considered irrelevant.

I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that we
want
to
say that a function has converged if at every $m$ both $c(m)$ and
$c'(m)$
converge. But every extra iteration back adds another point at
which
$c'(m)$ is undefined, so the function never converges in that
sense.
So, I think the user of the constrained version of the solver
function
should just be required to say how many periods from the end they
want
to
solve, and the number of gridpoints is periods+2. Like, if they
want
to
solve zero periods back, we need only 2 gridpoints (to define the
45
degree
line). If they want to solve 1 period, the function is piecewise
linear
with two segments, so we need 3 gridpoints, and so on. Does that
make
sense? If they want to define some convergence criterion
themselves,
they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able to
make
a
DemARK notebook to illustrate some of this as a companion to the
LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

These "breaking changes" are incredibly minor. Fixing the problem
merely
requires anyone using PerfForesightConsumerType to add
BoroCnstArt
and
aXtraCount to their dictionaries.  This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would
never
possibly
care about the consumption function, like 2000. Any kinks beyond
that
are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
<EMAIL_ADDRESS>

wrote:

"until the cFunc converges" requires some convergence
criterion.
If
that
criterion includes the MPC $c^{\prime(m))$, there IS no
interval
over
which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the
question
is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points
(corresponding
to
future constraints) at which the right and left derivatives are
different.
(Kink points).
 (That is, we should not go out
of
our
way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any
function
which "is" continuously differentiable (to arbitrarily many
derivatives)
over an interval can be (in the limit) represented with
arbitrary
accuracy
by polynomials (I think that's the gist of his theorem). I like
him
better
for pointing out the existence of functions that CANNOT be
represented
that way
.
Even if it is true that the limits of the left and right
derivatives
converge at every point, for any finite number of periods they
are
finitely
different for a finite number of points, which is an
abomination
(from
the
standpoint of people who want to stably represent functions in
discrete
terms like those that computers can easily handle). At those
points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence
criterion
for
the
LEVEL of $c$ that (say) should apply at every gridpoint, or
they
should
supply a number of periods backwards (otherwise they should be
required
to
define their own convergence criterion). But if they are
supplying
the
'level' criterion there is no reason to require them also
(redundantly)
to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the
integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an
infinite
horizon model-- it solves until the cFunc converges. If you
try
to
run
an
infinite horizon model with a borrowing constraint and
aXtraCount
set
to
None, then the solver will repeatedly add one more kink, over
and
over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the number
of
gridpoints in successive iterations isn't equal-- there's no
way
an
array
of size 258 and an array of size 259 can be "close"!
Eventually,
the
top
gridpoint becomes so high that there's an overflow error and
the
solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints
or
a
highest
value (relative to the lowest value). I sense that you're
going
to
suggest
that we change the distance criterion to mNrmSS, but that
would
have
very
bad effects in the perfect foresight model. The consumption
function
is
essentially constructed from "bottom upward" in the PF model,
so
mNrmSS
will very quickly return the same value on successive
iterations...
but
the
consumption function above it is way off from the correct
solution.
Note that you don't need to put this custom version into a
notebook
to
test
it. Just use developer mode on your computer and change your
branch
to
mine. If your (locally run) notebook imports HARK, then it
will
use
my
version!

Yes, but I want to SHARE this notebook with
referees/editors/the
universe.
If I could impose a requirements "econ-ark==" whatever in
which I
could
guarantee it would work, then that might be enough. To do that
we'd
need
to create a new dev branch (containing the breaking changes)
which
will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though
haven't
tested
until
we resolve whether this should be a "breaking change". I
don't
want
to
do
the thing of including a custom version of
ConsIndShockModel.py
in
a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is
necessary.
The
extra gridpoints are constructed on the fly, and there'll
be
one
of
them
added for each iteration, so the user doesn't need to
specify
that
number
in advance, just needs to specify how many periods back to
solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the
problem
should
be
solved one more period, there's no way to do that without
adding
more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this
thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK734ZZHHQIC6UJSN3BDPZPFPHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWVZQ#issuecomment-500132582
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAKCK722RM5A7E4QLKJ4HNLPZPFPHANCNFSM4HRRZV2A
.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFN5FNGVCYHFWJP7EQDPZPGZZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHW4NI#issuecomment-500133429,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFN7MMMWNDOBR6B4XRDPZPGZZANCNFSM4HRRZV2A
.

Good point.  Actually, generically, I think people don't think much about
what the terminal period solution should be, and (as you point out) it can
make a big difference in speed of convergence.  It actually sped up
Shujaat's problem a lot when I told him to assume that the "terminal
period" should be the solution to a buffer stock model rather than to
$c=m$.
On Sat, Jun 8, 2019 at 11:49 AM Matthew N. White<EMAIL_ADDRESS>wrote:

Adding that capability has been on my backburner for a while. It's always
felt a little weird that the (unconstrained) perfect foresight model can
take longer to solve than the income shocks model... merely because it
takes so many periods for human wealth to converge, and thus for the linear
cFunc to stop "backing up"! I'd like for the terminal period solver to
check whether it's an infinite horizon model, in which case it will use the
unconstrained perfect foresight solution as its initial guess (in both
PerfForesight and ConsIndShock). That will make the PF model "converge" in
just 1 or 2 periods (I think HARK ignores the convergence check on the
first pass).
On Sat, Jun 8, 2019 at 11:37 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

MaxKinks is fine. Or MaxPrds.
I wasn't asking to add a new terminal function, just asking what it was.
It's not worth either of our time to add that option.
On Sat, Jun 8, 2019 at 11:25 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

It's called aXtraCount, not aXtraGrid. We can call it anything you
want,
but if we're going to use a new variable name, I'd prefer to be direct,
with MaxKinks or something like that.
The terminal period solution is c=m, yes. Making making the terminal
period solver "more clever" is a different topic entirely, and would
take
real effort/thought/work. If you want this ready to use on your
project,
this is not something you should be asking for now.
-- mnw
On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

I see, so we are on the same page. But, I'm afraid that calling it
aXtraGrid might be confusing to users. Could we call it something
else,
like "NumCnstPrds" or something like that?
PS. I take it that the terminal function is $c=m$? An alternative
would
be for the terminal function to be the unconstrained analytical
solution.
On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

That's essentially what aXtraCount does; I just used that variable
name
to
be like the other models. You're specifying how many periods worth
of
kinks to care about, and throwing out everything beyond that.
That's
what
generates "convergence".
-- mnw
On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

If you prefer a different stopping condition, I can change it
to
aXtraMax,
where you specify a (very large) aNrm beyond which you would
never
possibly
care about the consumption function, like 2000. Any kinks beyond
that
are
considered irrelevant.

I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that
we
want
to
say that a function has converged if at every $m$ both $c(m)$ and
$c'(m)$
converge. But every extra iteration back adds another point at
which
$c'(m)$ is undefined, so the function never converges in that
sense.
So, I think the user of the constrained version of the solver
function
should just be required to say how many periods from the end they
want
to
solve, and the number of gridpoints is periods+2. Like, if they
want
to
solve zero periods back, we need only 2 gridpoints (to define the
45
degree
line). If they want to solve 1 period, the function is piecewise
linear
with two segments, so we need 3 gridpoints, and so on. Does that
make
sense? If they want to define some convergence criterion
themselves,
they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able
to
make
a
DemARK notebook to illustrate some of this as a companion to the
LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

These "breaking changes" are incredibly minor. Fixing the
problem
merely
requires anyone using PerfForesightConsumerType to add
BoroCnstArt
and
aXtraCount to their dictionaries.  This isn't a fight worth having.
If you prefer a different stopping condition, I can change it
to
aXtraMax,
where you specify a (very large) aNrm beyond which you would
never
possibly
care about the consumption function, like 2000. Any kinks
beyond
that
are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
<EMAIL_ADDRESS>

wrote:

"until the cFunc converges" requires some convergence
criterion.
If
that
criterion includes the MPC $c^{\prime(m))$, there IS no
interval
over
which
"the cFunc converges"
Of course there are many definitions of "converges" but
because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the
question
is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points
(corresponding
to
future constraints) at which the right and left derivatives
are
different.
(Kink points).
 (That is, we should not go
out
of
our
way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any
function
which "is" continuously differentiable (to arbitrarily many
derivatives)
over an interval can be (in the limit) represented with
arbitrary
accuracy
by polynomials (I think that's the gist of his theorem). I
like
him
better
for pointing out the existence of functions that CANNOT be
represented
that way
.
Even if it is true that the limits of the left and right
derivatives
converge at every point, for any finite number of periods
they
are
finitely
different for a finite number of points, which is an
abomination
(from
the
standpoint of people who want to stably represent functions
in
discrete
terms like those that computers can easily handle). At those
points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence
criterion
for
the
LEVEL of $c$ that (say) should apply at every gridpoint, or
they
should
supply a number of periods backwards (otherwise they should
be
required
to
define their own convergence criterion). But if they are
supplying
the
'level' criterion there is no reason to require them also
(redundantly)
to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made
the
integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's an
infinite
horizon model-- it solves until the cFunc converges. If you
try
to
run
an
infinite horizon model with a borrowing constraint and
aXtraCount
set
to
None, then the solver will repeatedly add one more kink,
over
and
over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the
number
of
gridpoints in successive iterations isn't equal-- there's
no
way
an
array
of size 258 and an array of size 259 can be "close"!
Eventually,
the
top
gridpoint becomes so high that there's an overflow error
and
the
solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of gridpoints
or
a
highest
value (relative to the lowest value). I sense that you're
going
to
suggest
that we change the distance criterion to mNrmSS, but that
would
have
very
bad effects in the perfect foresight model. The consumption
function
is
essentially constructed from "bottom upward" in the PF
model,
so
mNrmSS
will very quickly return the same value on successive
iterations...
but
the
consumption function above it is way off from the correct
solution.
Note that you don't need to put this custom version into a
notebook
to
test
it. Just use developer mode on your computer and change
your
branch
to
mine. If your (locally run) notebook imports HARK, then it
will
use
my
version!

Yes, but I want to SHARE this notebook with
referees/editors/the
universe.
If I could impose a requirements "econ-ark==" whatever in
which I
could
guarantee it would work, then that might be enough. To do
that
we'd
need
to create a new dev branch (containing the breaking changes)
which
will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc
Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though
haven't
tested
until
we resolve whether this should be a "breaking change". I
don't
want
to
do
the thing of including a custom version of
ConsIndShockModel.py
in
a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter
is
necessary.
The
extra gridpoints are constructed on the fly, and there'll
be
one
of
them
added for each iteration, so the user doesn't need to
specify
that
number
in advance, just needs to specify how many periods back
to
solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the
problem
should
be
solved one more period, there's no way to do that without
adding
more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this
thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK734ZZHHQIC6UJSN3BDPZPFPHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWVZQ#issuecomment-500132582

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK722RM5A7E4QLKJ4HNLPZPFPHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFN5FNGVCYHFWJP7EQDPZPGZZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHW4NI#issuecomment-500133429
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADKRAFN7MMMWNDOBR6B4XRDPZPGZZANCNFSM4HRRZV2A
.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK7ZFDGTZYTRWNH4T7ZLPZPIILA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHXD3Q#issuecomment-500134382,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCK7Z4V7LFF5K4EAHEK7LPZPIILANCNFSM4HRRZV2A
.

--

Chris Carroll

Yes. It's another example of solving a "nearby" easier problem to get a hot
start on the big problem.  The Bayer-Luetticke approach is analogous, for
me.
On Sat, Jun 8, 2019 at 2:57 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Good point. Actually, generically, I think people don't think much about
what the terminal period solution should be, and (as you point out) it can
make a big difference in speed of convergence. It actually sped up
Shujaat's problem a lot when I told him to assume that the "terminal
period" should be the solution to a buffer stock model rather than to
$c=m$.
On Sat, Jun 8, 2019 at 11:49 AM Matthew N. White<EMAIL_ADDRESS>
wrote:

Adding that capability has been on my backburner for a while. It's always
felt a little weird that the (unconstrained) perfect foresight model can
take longer to solve than the income shocks model... merely because it
takes so many periods for human wealth to converge, and thus for the
linear
cFunc to stop "backing up"! I'd like for the terminal period solver to
check whether it's an infinite horizon model, in which case it will use
the
unconstrained perfect foresight solution as its initial guess (in both
PerfForesight and ConsIndShock). That will make the PF model "converge"
in
just 1 or 2 periods (I think HARK ignores the convergence check on the
first pass).
On Sat, Jun 8, 2019 at 11:37 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

MaxKinks is fine. Or MaxPrds.
I wasn't asking to add a new terminal function, just asking what it
was.
It's not worth either of our time to add that option.
On Sat, Jun 8, 2019 at 11:25 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

It's called aXtraCount, not aXtraGrid. We can call it anything you
want,
but if we're going to use a new variable name, I'd prefer to be
direct,
with MaxKinks or something like that.
The terminal period solution is c=m, yes. Making making the terminal
period solver "more clever" is a different topic entirely, and would
take
real effort/thought/work. If you want this ready to use on your
project,
this is not something you should be asking for now.
-- mnw
On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

I see, so we are on the same page. But, I'm afraid that calling it
aXtraGrid might be confusing to users. Could we call it something
else,
like "NumCnstPrds" or something like that?
PS. I take it that the terminal function is $c=m$? An alternative
would
be for the terminal function to be the unconstrained analytical
solution.
On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

That's essentially what aXtraCount does; I just used that
variable
name
to
be like the other models. You're specifying how many periods
worth
of
kinks to care about, and throwing out everything beyond that.
That's
what
generates "convergence".
-- mnw
On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

If you prefer a different stopping condition, I can change it
to
aXtraMax,
where you specify a (very large) aNrm beyond which you would
never
possibly
care about the consumption function, like 2000. Any kinks
beyond
that
are
considered irrelevant.

I've thought about it a bit more and my view, translated from
the
metaphysics, is that the right definition of convergence is
that
we
want
to
say that a function has converged if at every $m$ both $c(m)$
and
$c'(m)$
converge. But every extra iteration back adds another point at
which
$c'(m)$ is undefined, so the function never converges in that
sense.
So, I think the user of the constrained version of the solver
function
should just be required to say how many periods from the end
they
want
to
solve, and the number of gridpoints is periods+2. Like, if they
want
to
solve zero periods back, we need only 2 gridpoints (to define
the
45
degree
line). If they want to solve 1 period, the function is
piecewise
linear
with two segments, so we need 3 gridpoints, and so on. Does
that
make
sense? If they want to define some convergence criterion
themselves,
they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be
able
to
make
a
DemARK notebook to illustrate some of this as a companion to
the
LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

These "breaking changes" are incredibly minor. Fixing the
problem
merely
requires anyone using PerfForesightConsumerType to add
BoroCnstArt
and
aXtraCount to their dictionaries.  This isn't a fight worth having.
If you prefer a different stopping condition, I can change it
to
aXtraMax,
where you specify a (very large) aNrm beyond which you would
never
possibly
care about the consumption function, like 2000. Any kinks
beyond
that
are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
<EMAIL_ADDRESS>

wrote:

"until the cFunc converges" requires some convergence
criterion.
If
that
criterion includes the MPC $c^{\prime(m))$, there IS no
interval
over
which
"the cFunc converges"
Of course there are many definitions of "converges" but
because
$c^{\prime}(m)$ is crucial for so many questions, I'd say
the
question
is
whether $c^{\prime}(m)$ converges monotonically at every
$m$.
It does not, because there are always these pesky points
(corresponding
to
future constraints) at which the right and left derivatives
are
different.
(Kink points).
 (That is, we should not go
out
of
our
way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that
any
function
which "is" continuously differentiable (to arbitrarily many
derivatives)
over an interval can be (in the limit) represented with
arbitrary
accuracy
by polynomials (I think that's the gist of his theorem). I
like
him
better
for pointing out the existence of functions that CANNOT be
represented
that way
.
Even if it is true that the limits of the left and right
derivatives
converge at every point, for any finite number of periods
they
are
finitely
different for a finite number of points, which is an
abomination
(from
the
standpoint of people who want to stably represent functions
in
discrete
terms like those that computers can easily handle). At
those
points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence
criterion
for
the
LEVEL of $c$ that (say) should apply at every gridpoint, or
they
should
supply a number of periods backwards (otherwise they should
be
required
to
define their own convergence criterion). But if they are
supplying
the
'level' criterion there is no reason to require them also
(redundantly)
to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made
the
integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
<EMAIL_ADDRESS>wrote:

You can't specify how many periods back to solve if it's
an
infinite
horizon model-- it solves until the cFunc converges. If
you
try
to
run
an
infinite horizon model with a borrowing constraint and
aXtraCount
set
to
None, then the solver will repeatedly add one more kink,
over
and
over
again.

Yay for it! That's the right thing to do!

The model is never considered "converged" because the
number
of
gridpoints in successive iterations isn't equal-- there's
no
way
an
array
of size 258 and an array of size 259 can be "close"!
Eventually,
the
top
gridpoint becomes so high that there's an overflow error
and
the
solution
collapses.

But, I think this is the right answer!

So we need to either specify a maximum amount of
gridpoints
or
a
highest
value (relative to the lowest value). I sense that you're
going
to
suggest
that we change the distance criterion to mNrmSS, but that
would
have
very
bad effects in the perfect foresight model. The
consumption
function
is
essentially constructed from "bottom upward" in the PF
model,
so
mNrmSS
will very quickly return the same value on successive
iterations...
but
the
consumption function above it is way off from the
correct
solution.
Note that you don't need to put this custom version into
a
notebook
to
test
it. Just use developer mode on your computer and change
your
branch
to
mine. If your (locally run) notebook imports HARK, then
it
will
use
my
version!

Yes, but I want to SHARE this notebook with
referees/editors/the
universe.
If I could impose a requirements "econ-ark==" whatever in
which I
could
guarantee it would work, then that might be enough. To do
that
we'd
need
to create a new dev branch (containing the breaking
changes)
which
will
exist in perpetuity that my code can insist upon.

-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc
Carroll <
<EMAIL_ADDRESS>wrote:

Just looked through the code -- it looks good (though
haven't
tested
until
we resolve whether this should be a "breaking change".
I
don't
want
to
do
the thing of including a custom version of
ConsIndShockModel.py
in
a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter
is
necessary.
The
extra gridpoints are constructed on the fly, and
there'll
be
one
of
them
added for each iteration, so the user doesn't need to
specify
that
number
in advance, just needs to specify how many periods back
to
solve,
right?
In
fact, if aXtraGrid is fixed and they specify that the
problem
should
be
solved one more period, there's no way to do that
without
adding
more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A

.

—
You are receiving this because you are subscribed to this
thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK734ZZHHQIC6UJSN3BDPZPFPHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWVZQ#issuecomment-500132582

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK722RM5A7E4QLKJ4HNLPZPFPHANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFN5FNGVCYHFWJP7EQDPZPGZZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHW4NI#issuecomment-500133429

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFN7MMMWNDOBR6B4XRDPZPGZZANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK7ZFDGTZYTRWNH4T7ZLPZPIILA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHXD3Q#issuecomment-500134382
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAKCK7Z4V7LFF5K4EAHEK7LPZPIILANCNFSM4HRRZV2A
.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFKNHYHGSYC7JPXTKBTPZP6ITA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXH3IZQ#issuecomment-500151398,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFKMWH77FOBOLGL6XW3PZP6ITANCNFSM4HRRZV2A
.

Sounds like you've worked out a plan here but some $.02 from me...

Yes, but I want to SHARE this notebook with referees/editors/the universe.
If I could impose a requirements "econ-ark==" whatever in which I could
guarantee it would work, then that might be enough.  To do that we'd need
to create a new dev branch (containing the breaking changes) which will
exist in perpetuity that my code can insist upon.

Unfortunately how we've got our notebooks set up now, they all use the same requirements.txt file, so you can only pin to one version across all notebooks.  However in the long run we should definitely change that, and in the short run you can just do the pip install econ-ark==$version from the notebook itself.
This is not great practice, but a short term fix when you're not certain how you want to implement a feature is to implement it one way in a dev release and then revert or change it in the next dev release.  Practically speaking it's not that different from when you accidentally release a bug in a dev release and revert the change in the next release.  It's a little annoying for dev release users, but your dev release users are the subset of users who've actively selected into being annoyed in exchange for access to the latest features.

Good point, notebooks get their versions from requirements.txt if they are being run by mybinder.  So a good temporary solution might just be to pip install econ-ark==[] whatever on the dev branch and then revisit this when we are ready to do the next stable release.
Matt, I hope changing this to be a non-breaking change is super easy?

Dev branch or dev release?
I'm not particularly well-versed with notebooks and binder, so I don't know
what will be problematic.
 -- mnw

On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Good point, notebooks get their versions from requirements.txt if they are
being run by mybinder. So a good temporary solution might just be to pip
install econ-ark==[] whatever on the dev branch and then revisit this when
we are ready to do the next stable release.
Matt, I hope changing this to be a non-breaking change is super easy?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A
.

I'm thinking we probably will need to rethink our approach to launching
notebooks, and  I have been communicating with Andrij about that.
In the meantime, the proposal is just to have a non-breaking version on the
dev branch, and revisit the issue when the new ideas for how to launch
notebooks have stabilized.
On Mon, Jun 10, 2019 at 7:32 PM Matthew N. White<EMAIL_ADDRESS>wrote:

Dev branch or dev release?
I'm not particularly well-versed with notebooks and binder, so I don't know
what will be problematic.
-- mnw
On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Good point, notebooks get their versions from requirements.txt if they
are
being run by mybinder. So a good temporary solution might just be to pip
install econ-ark==[] whatever on the dev branch and then revisit this
when
we are ready to do the next stable release.
Matt, I hope changing this to be a non-breaking change is super easy?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A
.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK77KTXHJWUWMAR4EGJ3PZ2F4DA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKSBAA#issuecomment-500506752,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCK725D7RCZ7W3TRSCUR3PZ2F4DANCNFSM4HRRZV2A
.

--

Chris Carroll

If it's non-breaking, why do we need it on a separate branch?
On Mon, Jun 10, 2019 at 3:17 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

I'm thinking we probably will need to rethink our approach to launching
notebooks, and I have been communicating with Andrij about that.
In the meantime, the proposal is just to have a non-breaking version on the
dev branch, and revisit the issue when the new ideas for how to launch
notebooks have stabilized.
On Mon, Jun 10, 2019 at 7:32 PM Matthew N. White<EMAIL_ADDRESS>
wrote:

Dev branch or dev release?
I'm not particularly well-versed with notebooks and binder, so I don't
know
what will be problematic.
-- mnw
On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Good point, notebooks get their versions from requirements.txt if they
are
being run by mybinder. So a good temporary solution might just be to
pip
install econ-ark==[] whatever on the dev branch and then revisit this
when
we are ready to do the next stable release.
Matt, I hope changing this to be a non-breaking change is super easy?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK77KTXHJWUWMAR4EGJ3PZ2F4DA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKSBAA#issuecomment-500506752
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAKCK725D7RCZ7W3TRSCUR3PZ2F4DANCNFSM4HRRZV2A
.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFKIJPFCYYAUD7VKXZDPZ2SETA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5OLY#issuecomment-500553519,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFMKJ7EFSKQVWZL4GPTPZ2SETANCNFSM4HRRZV2A
.

Not a separate branch -- just put it on the current dev branch.
Shauna's point was that just because you put something on the dev branch
doesn't mean it necessarily will go into the next stable release -- that
can be litigated at the point where the stable release's final form is
agreed upon.
On Mon, Jun 10, 2019 at 9:19 PM Matthew N. White<EMAIL_ADDRESS>wrote:

If it's non-breaking, why do we need it on a separate branch?
On Mon, Jun 10, 2019 at 3:17 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

I'm thinking we probably will need to rethink our approach to launching
notebooks, and I have been communicating with Andrij about that.
In the meantime, the proposal is just to have a non-breaking version on
the
dev branch, and revisit the issue when the new ideas for how to launch
notebooks have stabilized.
On Mon, Jun 10, 2019 at 7:32 PM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

Dev branch or dev release?
I'm not particularly well-versed with notebooks and binder, so I don't
know
what will be problematic.
-- mnw
On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Good point, notebooks get their versions from requirements.txt if
they
are
being run by mybinder. So a good temporary solution might just be to
pip
install econ-ark==[] whatever on the dev branch and then revisit this
when
we are ready to do the next stable release.
Matt, I hope changing this to be a non-breaking change is super easy?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK77KTXHJWUWMAR4EGJ3PZ2F4DA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKSBAA#issuecomment-500506752

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK725D7RCZ7W3TRSCUR3PZ2F4DANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFKIJPFCYYAUD7VKXZDPZ2SETA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5OLY#issuecomment-500553519
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADKRAFMKJ7EFSKQVWZL4GPTPZ2SETANCNFSM4HRRZV2A
.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK74NAH6VU52I75ZX4KTPZ2SK3A5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5SZA#issuecomment-500554084,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCK73GJLG3B67H5NNY5G3PZ2SK3ANCNFSM4HRRZV2A
.

--

Chris Carroll

That discussion was about a dev release, not a dev branch.  That's why
I asked before whether we were talking about a dev branch or a dev release.
The plan is to merge this PR into master, and then put it out in the next
dev release, with no breaking changes; is that correct?
On Mon, Jun 10, 2019 at 3:23 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Not a separate branch -- just put it on the current dev branch.
Shauna's point was that just because you put something on the dev branch
doesn't mean it necessarily will go into the next stable release -- that
can be litigated at the point where the stable release's final form is
agreed upon.
On Mon, Jun 10, 2019 at 9:19 PM Matthew N. White<EMAIL_ADDRESS>
wrote:

If it's non-breaking, why do we need it on a separate branch?
On Mon, Jun 10, 2019 at 3:17 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

I'm thinking we probably will need to rethink our approach to launching
notebooks, and I have been communicating with Andrij about that.
In the meantime, the proposal is just to have a non-breaking version on
the
dev branch, and revisit the issue when the new ideas for how to launch
notebooks have stabilized.
On Mon, Jun 10, 2019 at 7:32 PM Matthew N. White <
<EMAIL_ADDRESS>
wrote:

Dev branch or dev release?
I'm not particularly well-versed with notebooks and binder, so I
don't
know
what will be problematic.
-- mnw
On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

Good point, notebooks get their versions from requirements.txt if
they
are
being run by mybinder. So a good temporary solution might just be
to
pip
install econ-ark==[] whatever on the dev branch and then revisit
this
when
we are ready to do the next stable release.
Matt, I hope changing this to be a non-breaking change is super
easy?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK77KTXHJWUWMAR4EGJ3PZ2F4DA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKSBAA#issuecomment-500506752

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAKCK725D7RCZ7W3TRSCUR3PZ2F4DANCNFSM4HRRZV2A

.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFKIJPFCYYAUD7VKXZDPZ2SETA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5OLY#issuecomment-500553519

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADKRAFMKJ7EFSKQVWZL4GPTPZ2SETANCNFSM4HRRZV2A

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK74NAH6VU52I75ZX4KTPZ2SK3A5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5SZA#issuecomment-500554084
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAKCK73GJLG3B67H5NNY5G3PZ2SK3ANCNFSM4HRRZV2A
.

--

Chris Carroll

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFLWM6JGAO7DS3BVMW3PZ2S37A5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK63PQ#issuecomment-500559294,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFNWX4ES4OQPWNWAXQDPZ2S37ANCNFSM4HRRZV2A
.

  All branches other than master are arguably development branches.
I assume he meant to say "dev release", but please confirm that Chris.

Yes, that's what I'm asking.  My confusion (and thus original question) are
about the use of the term "dev branch".
 All branches other than
master are arguably development branches.
I assume he meant to say "dev release", but please confirm that Chris.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFLAIBL5OB7H5XC3U6DPZ2ULNA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK75AQ#issuecomment-500563586,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKRAFINVEUYHBMKDEFTJBLPZ2ULNANCNFSM4HRRZV2A
.

My understanding is that we have now moved to a workflow where we are
basically always on a Dev branch; when current Dev branch gets to point
where we are ready to publish a new "stable" release, then 1 nanosecond
later After we publish on master we create the next dev branch in
sequence.  Shauna, is that the right way to describe what we should be
doing things?
On Mon, Jun 10, 2019 at 21:39 Matthew N. White<EMAIL_ADDRESS>wrote:

Yes, that's what I'm asking. My confusion (and thus original question) are
about the use of the term "dev branch".
 All branches other than
master are arguably development branches.
I assume he meant to say "dev release", but please confirm that Chris.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=ADKRAFLAIBL5OB7H5XC3U6DPZ2ULNA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK75AQ#issuecomment-500563586
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADKRAFINVEUYHBMKDEFTJBLPZ2ULNANCNFSM4HRRZV2A
.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/299?email_source=notifications&email_token=AAKCK754PQCGTZSS4C64UZDPZ2UXPA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLAFXA#issuecomment-500564700,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCK7ZIPQT3NMEZMNVVNHDPZ2UXPANCNFSM4HRRZV2A
.

Thinking this over more, I guess what I described is not what we have been
doing - master branch has been where we put updates.  So I guess what I
should say is that when there is a no breaking version I want to push a Dev
release that I can reference ..
On Mon, Jun 10, 2019 at 21:51 Christopher Llorracc Carroll <
<EMAIL_ADDRESS>wrote:

My understanding is that we have now moved to a workflow where we are
basically always on a Dev branch; when current Dev branch gets to point
where we are ready to publish a new "stable" release, then 1 nanosecond
later After we publish on master we create the next dev branch in
sequence. Shauna, is that the right way to describe what we should be
doing things?