Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Come up with pattern to make it easier to change datatype of agent property #8

Open
KevinMcCarthyAtIDM opened this issue Dec 9, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@KevinMcCarthyAtIDM
Copy link
Collaborator

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

@KevinMcCarthyAtIDM KevinMcCarthyAtIDM added the enhancement New feature or request label Dec 9, 2024
@KevinMcCarthyAtIDM
Copy link
Collaborator Author

KevinMcCarthyAtIDM commented Dec 9, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants