* 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 age 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 age 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. Apologies accepted. 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 raises some prickly defensive hairs (this is my territory!), but your comments are very good. Thanks for pointing out some of the side-effects of concurrent programming. 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 -~----------~----~----~----~------~----~------~--~---
