extend drawByStrength() to provide a possibility of failure to find a match

[bhaller]

I wrote this just now in an email to someone, regarding their use of drawByStrength(). They have a bit of code saying "if drawByStrength() didn't find a mate, then self instead", but their model seemed to always find a mate, and thus never self. I wrote:

If they are always finding mates, that would suggest that the maximum distance for i2 is large enough that another individual is always within range. The drawByStrength() method will find all individuals within the maximum distance and then draw one proportional to interaction strength; so if there is any individual within the max distance, you WILL get an individual drawn. An interesting tweak to the model design might be, after drawByStrength() returns mate, get the interaction strength between individual and mate, and flip a coin with a probability based upon that interaction strength, and if the coin flip succeeds you use mate, but if it fails you self instead. That would basically model: just because there is a potential mate within the max distance, that doesn't mean that a mate WILL be chosen; beyond a certain distance, there begins to be some probability of selfing even though a possible mate does exist. Maybe that would provide more realistic dynamics.

This seems worth thinking about as an extension to drawByStrength() itself, I think, but I'm not sure what the right approach exactly ought to be. A new optional parameter that controls the tendency to find a mate vs. to fail; and the smaller the total of all interactions strengths is (i.e., the smaller the population density), the higher the probability of failing. @petrelharp what do you think of this? Do you have a vision for what the mathematically rigorous approach to this ought to be? It certainly seems like a useful extension, to the point that I'm surprised it hasn't come up before!

[petrelharp]

This sounds compelling but I'm not sure it's the right way round? Consider the case of finding a pollen parent, where 'interaction strength' is the amount of pollen from the other individual that ends up on the focal individual): the probability of finding or not a mate should depend on the total amount of interaction strength, and if you indeed outcross you choose a pollen parent proportional to their strength. Whether it succeeds should not depend on the strength of that chosen other individual.

More generally, it seems like if you pick a partner proportionally to strength and then only succeed with probability also proportional to strength, then you're double-counting 'strength'? I dunno, there's probably an example where that's the right behavior, but it's not seeming like the most natural one to me right now.

[bhaller]

This sounds compelling but I'm not sure it's the right way round? Consider the case of finding a pollen parent, where 'interaction strength' is the amount of pollen from the other individual that ends up on the focal individual): the probability of finding or not a mate should depend on the total amount of interaction strength, and if you indeed outcross you choose a pollen parent proportional to their strength. Whether it succeeds should not depend on the strength of that chosen other individual.

More generally, it seems like if you pick a partner proportionally to strength and then only succeed with probability also proportional to strength, then you're double-counting 'strength'? I dunno, there's probably an example where that's the right behavior, but it's not seeming like the most natural one to me right now.

Ah, yes, I think I was unclear above. In the quoted part I'm quoting what I wrote in slim-discuss (which was an early idea); but then below I write "A new optional parameter that controls the tendency to find a mate vs. to fail; and the smaller the total of all interactions strengths is (i.e., the smaller the population density), the higher the probability of failing." That's what I'm proposing, and it sounds like that is also what you think – using local population density, not just the strength of interaction with the one chosen mate. But how exactly should this be expressed? What should the new parameter be named, and what exactly should it do in terms of scaling the probability of failing to find a mate?

[petrelharp]

Ah right, sorry. How about:

• provide a parameter which I'll call C
• and then if the total strength (not population density) is T
• then the probability of choosing a mate at all is C * T (or 1 if this is bigger than 1);
• so that drawByStrength with this parameter set can return an empty list (or, self?) with probability 1 - min(1, C*T)

For a name for C um I dunno how about failureProbabilityScaling? Or noDrawScaling?

And I think it should probably be total strength not pop density since that's what describes, for instance, the number of available mates?

[bhaller]

Interesting, ok.

I see your point regarding total strength vs. population density. I think you're right, upon reflection. It means there will be an edge effect, for non-periodic-boundary models; but that's life; there is an edge, after all.

OK, C * T. I guess if the user wants a more absolute scale for the failure probability – like, "when at carrying capacity with a uniform spatial distribution, in the interior of the landscape, the probability of failure is X" – they can figure that out for themselves, or fit it by trial and error; probably trying to have C be defined in terms like that would be too high-level for SLiM and would make too many assumptions; not a good idea. People will figure it out. :->

Naming: ok, how about failureScaling? And I guess the default for that should be INF, specifying that by default (for backward compatibility, and also just as a good default) failure is not an option as long as at least one possible hit is within range.

[petrelharp]

Hm, maybe the probability is T/C and then C is called saturationLevel or something like that? Although then the default is 0 which is kinda less intuitive than INF. If it's C*T then failureScaling is fine, I can't think of anything better.