better automation of for loops over 'time varying' values

[sbenthall]

Time varying values are currently implemented as lists indexed by t.

This is to denote differently aged agents.

In some cases, there is a separate control flow for handling the time-varying values and the non varying values.

It would perhaps improve readability to have a more general, consistent way of handling time-varying values.

For example, if these time-varying values were arrays and not lists, it would be possible to perform vectorized operations on them, rather than use a (slower) for loop iteration.

[mnwhite]

They're lists because sometimes their elements are not compatible with being in an array. E.g. PermGroFunc in ConsGenIncProcessModel has a list of *functions*, which can't be cast to an array. It's uncommon that there's a use for vectorized operations on time-varying model inputs. When there is, I created an array from the list and worked with that. Any instance of a time-varying loop in the code is either because a) it's strictly necessary as there is no vectorized equivalent, or b) that code would only ever be run once, it takes essentially no time, and it's significantly easier to read as a loop.

…

On Tue, Dec 22, 2020 at 1:15 PM Sebastian Benthall ***@***.***> wrote: Time varying values are currently implemented as lists indexed by t. This is to denote differently *aged* agents. In some cases, there is a separate control flow for handling the time-varying values and the non varying values. It would perhaps improve readability to have a more general, consistent way of handling time-varying values. For example, if these time-varying values were arrays and not lists, it would be possible to perform vectorized operations on them, rather than use a (slower) for loop iteration. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#890>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFJ44GUZZWNG4LE4FRTSWDO5FANCNFSM4VF7AH5A> .

[sbenthall]

I thought you were on a break from HARK work @mnwhite ...

[sbenthall]

Since vectorization is not an option, it might be possible to use something like the following:

def apply_or_map(value, func):
    if timy_varying(value):
       return map(value, func)
    else:
       return func(value)

That would allow the code to be refactor in a way that operations could be written just once, rather than repeated over both the time varying and non-time varying cases.

I've notived this while working on this part of the code, but maybe there are other places as well.

https://github.com/econ-ark/HARK/blob/master/HARK/ConsumptionSaving/ConsPortfolioModel.py#L242-L262

[sbenthall]

Here is another example where the handling of time-varying and non-time-varying cases could be consolidated.

https://github.com/econ-ark/HARK/blob/master/HARK/ConsumptionSaving/ConsPortfolioModel.py#L277-L286

[sbenthall]

Here is another case:
https://github.com/econ-ark/HARK/blob/master/HARK/ConsumptionSaving/ConsPortfolioModel.py#L322-L342

[sbenthall]

Note there is a lack of parallelism here.

If RiskyDstn is not time varying, it is a scalar (float).

If it's an infinite horizon model with no age variation, then the solution is a single element list.

It would probably be best if these were the same structure (i.e., list or not, in the singleton case), for consistency.