IndShockConsumerType checkConditions() returns nothing, always

[sbenthall]

The checkConditions() method of IndShockConsumerType returns nothing whether or not the conditions it checks have been met.

Instead of returning, say, a boolean or an array of booleans corresponding to the checks, it prints statements to the user.

This is not ideal.
One reason it is not ideal is that it makes it difficult to write an automated test of this functionality--such as a test that an instance with a certain configuration would fail, or not, a condition.

See #504 #510

[mnwhite]

Doesn't the method write the value of the conditions to attributes like self.GIC? I think Chris did that?

…

On Sat, Feb 15, 2020 at 3:52 PM Sebastian Benthall ***@***.***> wrote: The checkConditions() method of IndShockConsumerType returns nothing whether or not the conditions it checks have been met. Instead of returning, say, a boolean or an array of booleans corresponding to the checks, it prints statements to the user. This is not ideal. One reason it is not ideal is that it makes it difficult to write an automated test of this functionality--such as a test that an instance with a certain configuration would fail, or not, a condition. See #504 <#504> #510 <#510> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#525?email_source=notifications&email_token=ADKRAFNEI4J3VXXHQYZBZHTRDBIXPA5CNFSM4KV4ER6KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INZRKSQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFMAT3NP6ZJEDKSUIFTRDBIXPANCNFSM4KV4ER6A> .

[llorracc]

Hmmm, it "returns" nothing but it would be a waste of time to work out an exact format for what it should return, since the combinatorics of all the various conditions and their implications are considerable and have no natural order to hem. What it DOES do is exactly what any user would want: It constructs the numerical value of the various conditions (the "Growth Impatience Factor" is [model].GIF), and the True-False value of whether various conditions are satisfied (after checkConditions(), the "Growth Impatience Condition" is either true or false.) The only really sensible return variable I could see adding is a boolean (true or false) about whether the problem has a nondegenerate solution. Only objection to that is that it's not at all obvious ex-ante that this is what "checkConditions()" should return. If it were named "checkNondegenerateSolution()" then it would make sense to return T/F ...

…

On Sat, Feb 15, 2020 at 9:52 PM Sebastian Benthall ***@***.***> wrote: The checkConditions() method of IndShockConsumerType returns nothing whether or not the conditions it checks have been met. Instead of returning, say, a boolean or an array of booleans corresponding to the checks, it prints statements to the user. This is not ideal. One reason it is not ideal is that it makes it difficult to write an automated test of this functionality--such as a test that an instance with a certain configuration would fail, or not, a condition. See #504 <#504> #510 <#510> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#525?email_source=notifications&email_token=AAKCK734VOVDAAIOVCHRKPDRDBIXLA5CNFSM4KV4ER6KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INZRKSQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK7447ZQ2VFKOVARPRNLRDBIXLANCNFSM4KV4ER6A> .

-- - Chris Carroll

[sbenthall]

@mnwhite Ah, yes, I see. You're right. It does set the instance state.
I was mistaken; it is easier to write tests for this than I thought.

[sbenthall]

@llorracc Something I'm finding is that the state that is set by the method appears to use a boolean, where True indicates that the condition is satisfied. That seems very natural to me. E.g.

HARK/HARK/ConsumptionSaving/ConsIndShockModel.py

Lines 2290 to 2303 in ad83315

	if GIF<1:
	self.GIC = True
	if public_call:
	print('The value of the growth impatience factor for the supplied parameter values satisfies the Growth Impatience Condition.', end = " ")
	if verbose:
	print('Therefore, a target level of wealth exists.')
	print()
	else:
	self.GIC = False
	violated = True
	print('The given parameter values violate the Growth Impatience Condition for this consumer type; the GIF is: %2.4f' % (GIF), end = " ")
	if verbose:
	print('Therefore, a target level of wealth does not exist.')
	print()

If the order does not matter but the conditions all have names, then it would make sense to return a dictioanry of booleans, where the keys are condition names and values are whether or not the condition was met.

[sbenthall]

The variable violated seems to track whether or not any of the conditions have been violated. But I think nothing is done with that variable.

[sbenthall]

Oh, interesting. The PerfForesightConsumerType class also has a checkConditions() method.
According to its docs, it returns None.
But according to the code, it returns a boolean based on whether or not any conditions were violated (True if any have been violated).
This is then passed the its subclass IndShcokConsumerType's checkConditions, which returns None (true to its documentation).

HARK/HARK/ConsumptionSaving/ConsIndShockModel.py

Line 1854 in ad83315

def checkConditions(self,verbose=False,verbose_reference=False,public_call=False):

The implemented type signatures of the superclass and subclass are different, though it stands to reason this should be the kind of thing with a clean inheritance structure with isomorphic type signatures.
The documentation is inaccurate on at least one of the classes.

There is room for improvement here.

[llorracc]

Improve away! Ps. The various conditions and implications are articulated in the tables linked at the end of the buffer stock remark. Pps. Note that the nature of tests would be, e.g. if the WRIC and FVAC are satisfied, the decision rule (= consumption function) should converge. Not obvious how best to test for “convergence”; one crude way would be to solve for say 100 periods and then see if, at end-of-period grid values of a, the predicted c’s are moving less and less as you continue iterating. That is, for give a[i], Delta upinv(a) gets smaller as you go further back. If this doesn’t make sense to you I can elaborate.

On Sat, Feb 15, 2020 at 23:20 Sebastian Benthall ***@***.***> wrote: Oh, interesting. The PerfForesightConsumerType class also has a checkConditions() method. According to its docs, it returns None. But according to the code, it returns a boolean based on whether or not any conditions were violated (True if any have been violated). This is then passed the its subclass IndShcokConsumerType's checkConditions, which returns None (true to its documentation). https://github.com/econ-ark/HARK/blob/ad833152145529dc0f0f47d6c575a95a542967cd/HARK/ConsumptionSaving/ConsIndShockModel.py#L1854 The implemented type signatures of the superclass and subclass are different, though it stands to reason this should be the kind of thing with a clean inheritance structure with isomorphic type signatures. The documentation is inaccurate on at least one of the classes. There is room for improvement here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#525?email_source=notifications&email_token=AAKCK73T6LUNTRZXHOFIXJLRDBTCBA5CNFSM4KV4ER6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3YIRQ#issuecomment-586646598>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK757F6P2T76H3BB6HV3RDBTCBANCNFSM4KV4ER6A> .

-- Sent from Gmail Mobile