* Starting to see your point. In a 100 CPU case, where 98 CPU's have finished, we would find that the last few hosts that need to be calculated are suddenly a 100 years older, and probably just drop dead. That could be remedied by passing the year as a value of the agent, but then your second point indeed becomes valid (people always dying from the 100th CPU). That wasn't much of a problem when all the year increments sort of happened at the end of the 8-year cycle.
> If I were modeling it I would always do death then birth. I would have > birth be dependent on pop. Having death before birth does mean that it > is ignored the chance of mating just before death, but that is a tiny > consideration next to the mammoth issue of how good a model birth by > pop is. * Birth is density dependent already. I've a limited number of free slots (1000), and I am randomly picking a second slot to see if it contains a father (and I pick a mother from the population of living - hence no allee effect). This results in density-dependent birth. > you seem to be evaluating birth as a 50% probability at empty > locations, which is not obvious to me why unless you are dealing with > a saturated population. * Just a small trick. I wanted the max birthrate to be 0.5 children per host per year. I could have changed the models to work in timesteps of 24 months, and then have 1 birth, 2 death, 4 infection and 10 evolution events, but in this way I've 0.5 birth, 1 death etc.. while keeping the model in a timestep of 1 year. > I would propose age death check every living entity, > total pop birth rate check, random infections/evolutions > based on probabilities applied only as needed > [need to control the pop from exploding by having some downward factor > either in birth or death relative to the population - infection > increasing death rate is enough to satisfy this?] * I need a carrying capacity in the absence of an infection as well. The density dependent birth I described above makes sure I do have a carrying capacity. Think of it as iceland, which through the centuries had a population limited by food availability. > As your death and birth are year dependent, I would argue there is > definitely a bias (albeit randomly applied so you probably wouldn't > notice with only 8 cpu). * As discussed above ;), I now agree. > So not only would modeling each location as an agent simplify the > model, it would probably perform better in a realistic computer. * Shouldn't be hard to change. Thanks for your and chouser's feedback on the most practical model for concurrency. > > Why do I :gather the way I do. > > * Rich also commented on this one. I'm not sure how to do it better. > > I'll look into it. > Assuming you were to make every location an agent, it would make sense > to instead of having a world of locations, instead only have a > collection of living hosts which can increase and decrease in size. > Then actually the only gathering you would be doing is in the > reporting (to look at infections). Another advantage to many agents? * Locations are currently my way of limiting the population size (if you'd plot the saturation curve as the population reaches carrying capacity, it is identical to the classical (1 - popsize/carrying capacity)). Changing it to a vector of agents (I need random access!) would be a bit more of a rewrite. Perhaps someone can explain me in more detail the downside of :gather?, so that I understand why it is worth doing? > Apologies for going so far off the original question, its an > interesting simulation :) > Thanks for showing the code. > Regards, > Tim. No need to apologize. I might need to though ;). I'm currently in the last few months of my phd (evolution of the immune system), and this simulation is the basis for my last article. So naturally, having someone on a computer language forum comment on the way I set up my simulation raised some prickly defensive hairs (this is my territory!), but your comments are very good. Thanks for pointing out some hairy side-effects that concurrent programming has on my model formalism. I'll have to get more used to thinking concurrently :). Have a good christmas! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
