Things to be done:

• Update population's genome_length
• Update the population's abundances vector
  • Add entries for all of the genotypes that can be encoded with the extra bit
• Update the population's delta vector
  • Add entries for all of the genotypes that can be encoded with the extra bit

Converting between individuals and their genotype with gamma adds baggage. Move W_g (fitness of genotype) and a{g,l}_ (allelic state of genotype g at locus l) to W_i and a{i,l}_? These seem a bit odd, especially the former.

The number of ones for each genotype can definitely be stored ahead of time and then filtered with abundances > 0 when needed.

Make sure choices for A and L are such that there's constant pressure for change

After growth/mutation/etc., check to make sure that the population hasn't grown bigger than maxint. Would checking if values are still non-negative work?

• 0.05
• 0.10
• 0.50 (base)
• 1.00 (to match delta + epsilon)
• 1.50
• 2.00

Fitness is affected by how long the genome is for each population.

Possibilities:

• Create a single fitness landscape for the maximum genome length and have fitness be the sum of the fitness effects at the available loci

During migration, the genome lengths of the source and destination populations can be different. When adding immigrants to a population, adjust their abundances by stripping out bits that are inaccessible in the new environment.

Probably best to default to False.

• 0
• 0.1x
• 1x
• 5x
• 10x

once all the other kinks are ironed out.

P for a population and p for the proportion of cooperators could be confusing. Clearer way to present these?

FST?

Create a function that removes non-visible loci from a list of abundances. This is what's done in handle_immigrants, but it could also be used elsewhere (e.g., randomize).

• 0.01
• 0.05 base rate
• 0.10
• 0.20

Because they're still producers and are constructing their environment, they just have some loci that do not contribute to fitness.

Most of the time, the abundances of producers with non-visible loci will be zero, but it is possible if mutations are allowed at non-visible loci.

Finish implementing get_mutation_probabilities

Code like 2**(self.genome_length + 1) is frequently used when initializing vectors used by Population. This code is slightly hard to read and easy to mess up. Add a num_genotypes property to Population objects that stores the number of genotypes and is updated whenever genome_length is, perhaps best through a set_genome_length function.

Make an Experiment object that creates the Metapopulation and cycles through the updates. This object could also store the configuration, so Metapopulation and Population objects (and others) don't have to store pointers to the config.

As an alternative view of fitness/adaptation.

I don't see any limits on the number of figures, so it may be worth considering.

divmod(id, ncols) will return a tuple containing the row and column. fast.

I think @KatieDickinson votes for "adaptive loci", oui?

Per Brian...

• public good durability (we’ve definitely read about this in Tea. Sam Brown? maybe 10.1086/667193)
• effects of diffusion of public good (pretty sure one of the durability papers also talked about this)

This limits the genome lengths that can be used. Replace with on-demand calculation of the HD to each other genotype.

Is there a possible speedup for this? First get the candidate genomes to mutate based on binomial sampling?

Would be easiest to just randomly generate the landscape for each one.

This should also be possible,

• Update description
• Update ordering in fitness equation
• Switch ordering in mutation equation