Adds config option for number of diseases per starting agent

[colinhanrahan]

This is a new kind of config option we haven't seen before. It's not passed down to children or used for replacement agents. (Options like the starting quadrant aren't passed down to children but are used for replacement agents.) To account for this, I had to add an agent variable that's only used for the initial population of agents. There might be a better way to do this by separating the logic for this new endowments from the rest of the endowments, and then using that in configureDiseases directly so you don't have to go through the agent.

Edit: writing a new randomizeStartingAgentEndowments method for endowments that are only used for the initial population (this is the only one so far).

[nkremerh]

You're right this is wonky. This is more of an environmental/simulation level option, so I'd like to avoid making this a property of the first generation agents.

You know how many agents there will be, and you know the range of starting diseases. You could create a list containing the number of diseases to give each agent (with however many repeated occurrences from cycling through the range over and over). Shuffle the list. Then divvy out the number of diseases by popping the list and applying that many diseases to an agent. All this can be done in sugarscape.py without changing the agent data structure.

[colinhanrahan]

@nkremerh This looks a little better. I decided not to write a new function to randomize endowments that are only for initial agents since it's a pretty niche use case.

[nkremerh]

It would be preferable to maintain the original way of seeding initial diseases in the simulation. If a number of starting diseases is set, but diseases per agent is [0, 0], then the current master branch behavior should happen (infect X number of agents with a unique disease at the start).

[colinhanrahan]

The book specifies X random diseases will be given to each agent, not X random diseases that they are not immune to, so I left that in with the new logic. We should probably just go one way or the other. I tested

• making sure each disease has different tags (currently, they can have the same tags)
• making sure agents were not immune to the diseases they were being given (with the new distribution logic)

and both of these resulted very quickly in population extinction.

[colinhanrahan]

• Do we need sugarscape.diseases, or can I remove it? It's not used for anything.
• disease_basic.json immediately goes extinct with the Hamming distance check, so that's something to think about.

[nkremerh]

We may as well keep it. The list of diseases could be useful for future research.

I take it you mean the sheer number of diseases and the provided immune system length make survival impossible?

[colinhanrahan]

Yes. I'm checking the 10 out of 25 diseases per agent version, which is supposed to be more difficult to survive, but not that much more difficult. To be fair, the actual symptoms diseases inflict are never disclosed in the book other than a vague "metabolic fees." I'll reduce the metabolism penalties and try to get a closer match with the book.

[nkremerh]

Something seems broken now: making the single change to the default config startingDiseasesPerAgent to [0,1] causes 100% of agents to have a disease in my testing.

[colinhanrahan]

This works with everything I tested but having three conditionals per loop isn't particularly glamorous.