Repository navigation
RANDOM-NUMBERS.md: what per-agent streams would need - #20
Merged
Merged
Conversation
The note already said that a counter-based generator makes per-agent streams possible and that they are not implemented. Two things are added, both learned while testing. First, a model can be invariant even though the engine is not: a model that fixes the order of its own draws, by sorting the agents that draw before drawing for them, gives the same results at any thread count. That is worth knowing for anyone who needs runs comparable across machines, and it is easy to mistake such a model's invariance for the engine's. Second, what per-agent streams would require. A draw keyed by agent, step and index follows the agent rather than the thread, so results stop depending on the thread count, on the division of work and, in a distributed run, on which process owns the agent. The key must be stable across threads, processes and restarts, which AgentUid is not: it is an index with a reuse counter, unique within one process. The identifier the shared I/O library defines, unique for the whole run and never reused, is exactly that key, so the change belongs with step 3 rather than before it. Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: markomanka <14293317+markomanka@users.noreply.github.com>
Almost certainly nothing. A model that draws through BioDynaMo's Random compiles unchanged and runs, with different numbers; none of the demos or tests needed a change. Exactly two interfaces changed, both failing at compile time rather than silently: SetGenerator, which is gone, and SampleImpl, which takes a Random* instead of a TRandom*. A one-line grep tells an author which case applies. What does need attention is not code but references: tests comparing against stored output of a stochastic run will fail and must be regenerated, and such a failure says nothing about the model. The section ends with the point that a model whose conclusions change when the stream changes was never reproducible, only self-consistent, so running one on both versions is a check on the model as much as on BioDynaMo. Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: markomanka <14293317+markomanka@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Two additions to RANDOM-NUMBERS.md. What an existing model has to change: almost certainly nothing, since a model drawing through BioDynaMo's Random compiles unchanged; exactly two interfaces changed and both fail at compile time, and what needs regenerating is stored reference output, not code. What per-agent streams would need: a key stable across threads, processes and restarts, which AgentUid is not and the shared I/O library's identifier is, so the change belongs with step 3. Also records that a model can be thread-count invariant while the engine is not, by fixing the order of its own draws.