Closed pierucci closed 7 years ago
The user interface part is extremely easy: there should be a state_cycle
parameter, similar to markov_cycle
.
state_cycle
would increment depending on the time a person spends in a state.
Now for the implementation...
I see 3 ways of implementing it:
state_cycle
into tunnel states. This would allow us to keep the existing implementation.Advantages and drawbacks of the different approaches:
1 | 2 | 3 | |
---|---|---|---|
Code rewriting | Extensive. Like, an entire new package. | Limited to matrix eval, but very complex | Limited to matrix definition (and maybe use different linear algebra functions to optimize matrix eval) |
Complexity | Easy (solved problem) | Extremely complex (CS PhD level!) | Probably easy, but we should check the consequences in details |
Computational complexity | Average _O(n_sim )_ |
Terrible. Impossible. _O(n_state ^n_cycle )_ |
Probably easy (product of sparse matrices of size n_state + n_time_varying_state * n_cycle ) |
Result | Imprecise probabilistic result | Exact result | Exact result |
I think solution 3 is worth looking into.
Solution 3 is mostly implemented & working with 66976b5cc984784021ac9ce6da0b25e645435139. But the TM and states are expanded anew for each model evaluation, this will significantly slow down PSA & co. The expansion part should be included in run_models()
.
This update just made most microsimulation models obsolete I think?
state_cycle
should work in define_parameters()
. To achieve that the expressions in TM and states should be fully expanded (but not evaluated) with parameters references before running the state_cycle
detection.
I want to believe.