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
To 100% test whether my issues with fitting SIS models are really due to over-flowing the range of a uint8, I went in to promote it to a uint16 and check whether behavior improved.
Confirmed that this indeed did appear to be the issue. However, just wanted to note that we might want to go back to the practice of defining something like the "ITIMER_TYPE" parameter that's used throughout, because I had to go change "uint8" to "uint16" in about 8 places, in 2 different files. Not the end of the world but a potentially error-prone process
The text was updated successfully, but these errors were encountered:
Also noting that I have one Infection class for SIR-type dynamics (itimer counts down to zero and infectiousness ends), and another for SIS-type dynamics (itimer counts down to zero, infectiousness ends, susceptibility gets set back to 1). Both of them interact just fine with the same "Transmission" step as long as both use the same signature for the itimer. But when I ran the test I described above, I promoted itimer to uint16 in the InfectionSIS class and the Transmission class but not the regular Infection class, and transmission then had a type mismatch with the SIR-type Infection class.
Luckily this is an easy-to-find error as error messaging on dumpy type mismatches is quite good. Again, should be solved as long as all references to itimer in function signatures referred back to a common ITIMER_TYPE
To 100% test whether my issues with fitting SIS models are really due to over-flowing the range of a uint8, I went in to promote it to a uint16 and check whether behavior improved.
Confirmed that this indeed did appear to be the issue. However, just wanted to note that we might want to go back to the practice of defining something like the "ITIMER_TYPE" parameter that's used throughout, because I had to go change "uint8" to "uint16" in about 8 places, in 2 different files. Not the end of the world but a potentially error-prone process
The text was updated successfully, but these errors were encountered: