Add support for randomness customization #13
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of forcing
Pcg64Mcg
. This PR adds ability to pass in a custom random generator for each model component (Generator, Excl. Gateway, Stochastic Gate, Processor), if None is provided a global rng will be used as previously.I'm using
Rc<RefCell<dyn Debug + RngCore>>
for storage which is required because of possible type variance of rng's inModel
structs (generics wouldn't work; requires variadic generics). As a side effect, this allows multiple Models to share the same rng.I tested a simulation using this change and it didn't break. Not sure about performance impact, but simulation performance should be a bit worse because of the added jump and vtable lookup each time rng was previously used.
Let me know whether there's anything you'd like to change/improve in what I've done in this PR so far, or it's okay as it is.
Before merging I'd like to rename
uniform_rng.rs
to something else, or possibly move its contents to parentmod.rs
. I'd appreciate your opinion on this.Maybe unwanted changes
Services
struct now skips deserializing the randomness source as well (and constructs the default).RngCore
struct can be the global rng doesn't make sense to deserialize it anyway. Manually calling the (currently non-existant) rng setter seems like a better option.