-
Notifications
You must be signed in to change notification settings - Fork 1
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
Predict2.0 #153
Predict2.0 #153
Conversation
Ok, I'll take this from here. |
Ok, made the changes here. I didn't do the notebooks, so please fix those. You just pass the time now, not a vector with the time in the second element. |
Oops. Think I just fixed that. |
I found this: |
Is this way more accurate than calculating all the points? |
Post plot? |
Hmm... the output should be the same. I did change the time since you were indicating the 100th timepoint before, and now it's 100.0 hrs. Maybe you could figure out what time the 100th point is, and then set it to that? |
Also adding more concentrations may help find the issue. Because there's oscillatory behavior the result doesn't have to be monotonic, but it should be locally smooth. |
Of course. Thank you. |
Could I keep it in the notebooks? |
|
This is related to my post on #general. Should be fixed now, but juptyerlab won't be available until I hear back from seasnet. |
Thanks. |
Sometimes the cell number becomes negative. I put an assertion for that, I will try to see if this used to happen before the change to the jacobian. |
I guess there is something wrong with the The y-axis is the number of cells, and the x-axis is a range of gamma_1. @aarmey do you see any other point that might be going wrong here? |
Something that looks weird is that with a higher concentration (this is in gemcitabine) the G2 rate progression -- which also happens to be division rate -- increases! I searched a little to see if I could find some evidence of this, but couldn't. |
Actually, there is something wrong with the |
Since the solution in |
Yep. In that case get rid of predict2 |
Some updates:
There are two errors now.
|
@aarmey I can't figure out what array dimension is wrong. Could you pleeease take a look at this error? When nD1 is estimated to be 0 for lapatinib, this error happens. I mean when the matrix dimension for death in G1 becomes zero. The fitie_difference breaks in this. I tried a few tricks to just remove that parameter, but it breaks other things. I would really appreciate if you could take a look at this. Any recommendations helps. |
for ii = 1:length(G1) | ||
G1[ii] = sum(v[1:nG1]) + sum(v[(nG1 + nG2 + 1):(nG1 + nG2 + nD1)]) | ||
G2[ii] = sum(v[(nG1 + 1):(nG1 + nG2)]) + sum(v[(nG1 + nG2 + nD1 + 1):(nG1 + nG2 + nD1 + nD2)]) | ||
if nD1 == 0 & nD2 != 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need an if statement here? If nD1 is equal to 0 doesn't it just end up having no effect on addition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In either of G1 or G2, the second term sum(...)
would be meaningless, for example in G1, since it is summing the index nG1+nG2+1 : nG1+nG2
if nD1= 0.
If we're not ultimately using predict2, then what do we need to keep from this branch? |
I was trying to address the issues in the gradient here, but you are right, I could do it in another branch. |
This error I mentioned still exists even with what it is in the branch master. It is for the control trial in lapatinib. |
Yes, if there's nothing you need here, it'd be helpful for debugging to make a failing case off of master. |
No description provided.