Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add isotype to mutation model simulation #83

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

willdumm
Copy link
Contributor

@willdumm willdumm commented Apr 4, 2022

Without otherwise changing the simulation in mutation_model.MutationModel.simulate, adds isotype switching according to a new rate parameter isotype_lambda.

Copy link
Collaborator

@wsdewitt wsdewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple comments on isotype mutations

Comment on lines 163 to 172
def mutate(self, lambda0=0.01):
"""Returns a new isotype object, which may be of the same class, or may be
a later class.
"""
newisotype = self.copy()
if scipy.random.poisson(lambda0) > 0:
n = len(self.order) - newisotype.isotype
if n != 1:
newisotype.isotype = self.isotype + scipy.random.randint(1, n)
return newisotype
Copy link
Collaborator

@wsdewitt wsdewitt Apr 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about the Poisson rv here—you are using it to make a binary choice? Shouldn't n be based on the Poisson draw, rather than drawn uniformly (but then truncated based on the terminal isotype)?

I would also suggest documenting lambda0 in the docstring.

It's also implicit here that this function simulates for one unit of simulation time, so I wonder if it would be better to put this code in the mutation_model.MutationModel.simulate function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm yes this doesn't make sense... I wrote this deferring thought and then forgot to come back and think about it.

I'm not sure how this should be done, though. I think we talked about fixing a probability of switching occurring and then choosing uniformly from the available states. I'm not sure if we want to choose from the available states according to a poisson process, because it's not clear that one isotype transition is more likely than another.

So I propose changing lambda0 to p, which is the probability that class switching will occur in one time step, and replacing line 168 with a comparison of p to a uniform draw from the unit interval.

@willdumm
Copy link
Contributor Author

What I've done instead is add a parameter transition_probabilities, which allows the user to pass an arbitrary transition matrix, in which rows are probability distributions on target isotypes. These transition probabilities are different than the weights attached to isotype objects, since larger weights should correspond to lower probability transitions. I considered relating the two by taking the log of probabilities, but I think it better to just separate them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants