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
PR #1324 fixed an issue where fixations were not being "pruned" even when that option was True.
With that fix, though, we have the following behaviors:
genetic values are calculated BEFORE and fixation pruning
Therefore, fixations are part of the genetic value calculation!!
Including them is the right thing to do for additive model and is
"fine" for multiplicative models b/c the way we choose parents
only requires that we know relative fitnesses.
However, certain operations may be annoying.
For example, tracking mean fitness over time in "standard pop gen" scenarios
requires correcting values stored in metadata by the effect sizes
of fixations that generation.
(This situation is even more obnoxious when we are not tracking
counts each generation -- fixations since the last simplification
accumulate.)
Ultimately, these issues are all due to fwpdy11 being written to simulate
traits and all the "pop gen" stuff is bolted on top.
It may be possible to move the order of when genetic values are calculated
to AFTER fixation removal.
Dealing with the simplification issue described above is harder -- we don't necessarily
know the counts.
The text was updated successfully, but these errors were encountered:
Quick experimentation changing the order of events results in most tests passing but the sweep tests seem to loop forever, implying that how we are monitoring for fixations is depending on the mutations being found in genomes.
PR #1324 fixed an issue where fixations were not being "pruned" even when that option was
True
.With that fix, though, we have the following behaviors:
Including them is the right thing to do for additive model and is
"fine" for multiplicative models b/c the way we choose parents
only requires that we know relative fitnesses.
For example, tracking mean fitness over time in "standard pop gen" scenarios
requires correcting values stored in metadata by the effect sizes
of fixations that generation.
(This situation is even more obnoxious when we are not tracking
counts each generation -- fixations since the last simplification
accumulate.)
Ultimately, these issues are all due to fwpdy11 being written to simulate
traits and all the "pop gen" stuff is bolted on top.
It may be possible to move the order of when genetic values are calculated
to AFTER fixation removal.
Dealing with the simplification issue described above is harder -- we don't necessarily
know the counts.
The text was updated successfully, but these errors were encountered: