API for parameters does not take np.array type about hark HOT 14 CLOSED

from hark.

@sbenthall could you help me with this? I'm not familiar with the logging features of HARK

from hark.

I'm confused about how to reproduce this error.

1. Why is this issue on HARK and not in the DistributionOfWealthMPC repository? Is that a mistake?
2. I'm trying to reproduce the error, but running cstwMPC.py gets me this error:

$ python cstwMPC_MAIN.py 
Traceback (most recent call last):
  File "/home/sb/projects/econ-ark/DistributionOfWealthMPC/Code/cstwMPC_MAIN.py", line 65, in <module>
    if param_name == "DiscFac":
NameError: name 'param_name' is not defined

3. Going into the Code/ directory and trying to run cstwMPC_MAIN.py get me:

$ python cstwMPC_MAIN.py 
Traceback (most recent call last):
  File "/home/sb/projects/econ-ark/DistributionOfWealthMPC/Code/cstwMPC_MAIN.py", line 65, in <module>
    if param_name == "DiscFac":
NameError: name 'param_name' is not defined

So I haven't gotten to the logging issue yet.

from hark.

OK, I've replicated this error by working from the cstwMPC.ipynb notebook.

from hark.

Correct, this happens in the cstwMPC.ipynb file. Probably should have put it on DistributionOfWealthMPC but I assumed fixing it would require changes in HARK.

from hark.

The error is happening because:

• The value of self.conditions['GICRaw'] is an np.array, [True].
• This value is being passed to messages[self.conditions[name]] as a key to the dictionary messages
• The keys of messages are expected to be booleans, not arrays of booleans.
• The condition that is causing the failure is the one tested by check_GICNrm. This is hard to discover, because there is an error in the code whereby this conditions has the name GICRaw -- probably an error from copying and pasting code.
• The reason why the result of its test is an array [True] is because self.thorn is a single-valued array.
• The reason why self.thorn is a single-valued array is because self.DiscFac is a single-valued array.

Did self.DiscFac become array-valued in some recent change to HARK? Is that because it is time-varying? Or otherwise multivalued?

If so, how shall we compute thorn?

from hark.

from hark.

@dedwar65 The notebook is here:

https://github.com/econ-ark/DistributionOfWealthMPC/blob/master/cstwMPC.ipynb

If I recall correctly, the whole point of the DistributionOfWealthMPC paper is that the DiscFac is being estimated.
Perhaps it is the estimation code of cstwMPC that is returning an array value for the DiscFac when HARK expects a scalar value.

@alanlujan91 do you know if this logging error happens with HARK pinned to 0.12, or is it the updates to get it to work with master that are causing the break?

from hark.

• Patch to the conditions code to take 1st element of DiscFac of single valued array
• Complain if DiscFac has more than one value in its array.

from hark.

@sbenthall error does not happen in econ-ark=0.12

from hark.

Thinking this over -- I am doubtful that it is a good idea to patch HARK with this change.

There is already something in check_conditions that checks to make that the model is an infinite horizon problem with only a single stage:

https://github.com/econ-ark/HARK/blob/master/HARK/ConsumptionSaving/ConsIndShockModel.py#L2054-L2055

So it would require some severe abuse of the API if DiscFac were a list instead of a scalar.

Since this was not a problem with earlier HARK versions, it is most likely that this bug was introduced in DistributionofWealthMPC.

In other words, HARK is working as expected, and the fix should be done in the DistributionofWealth repo.

from hark.

Hmmm... there is one condition under which it would make sense to patch HARK, but it would be a more general issue.

Currently, we have scalar values (e.g. floats) for parameters, and optionally lists if a parameter is time-varying.
I.e. I believe it is invalid, according to the API, to have array-values parameters (though we may be doing that in some places because both lists and arrays are 'iterable'). (Indeed, the 'must be lists' according to @mnwhite in #664 )

We could conceivably change the HARK API to accomodate array-valued parameters. Maybe that could be part of a broader effort to make the API more strongly type. This is discussed here: #664

But this is a bigger effort than should be done for the 0.13.0 release.

from hark.

This relates to the project that @alanlujan91 and I had sketched in which we would basically make everything age-varying (in principle). We should discuss the way forward in depth at some future meeting.

from hark.

I think I found the bug and it is unrelated to logging or Discount Factor being time varying. Since HARK 0.11 the representation of discrete distributions has changed, from 1 dimensional vectors to 2 dimensional where the second dimension indexes the random variable for multidimensional random variables.

from hark.