You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current approach to handling discounting seems a bit verbose. As I understand it, you need to use rescale_discount_rate in all discounted outcomes if you use a cycle length other than one year.
That seems like something that could pretty easily be simplified by having an input to run_model representing the cycle length. This is already done for partitioned survival models, but it makes just as much sense for Markov.
Once the timescale is properly defined, no rescaling would be necessary.
Other potential benefits:
A consistently scaled measure of time available in parameter evaluation
Define the number of cycles automatically by supplying the timeframe
The text was updated successfully, but these errors were encountered:
I am not against this idea, and specifying the total time and cycle length sounds good. But handling discounting does not need to be so verbose. The way I've been doing it is to define the discount rate as a parameter, so you use rescale_discount_rate just once.
The current approach to handling discounting seems a bit verbose. As I understand it, you need to use rescale_discount_rate in all discounted outcomes if you use a cycle length other than one year.
That seems like something that could pretty easily be simplified by having an input to run_model representing the cycle length. This is already done for partitioned survival models, but it makes just as much sense for Markov.
Once the timescale is properly defined, no rescaling would be necessary.
Other potential benefits:
The text was updated successfully, but these errors were encountered: