You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! Another issue - also happy to help fix this one if a quick PR is helpful. I was doing some testing of a single perturbation before starting a long run of them, and found that when perturbations all turn out to be NP, the RunMixscale function errors out.
It looks like it might be coming from this line of the code, where the cell types are drawn from the name of the first perturbation added to gv.list. In cases where gv.list is empty however—which I think happens when all the perturbations are NP—I get a subscript out of bounds error coming from trying to access gv.list[[1]].
One fix for this could be to derive the cell types from the splits variable.
The text was updated successfully, but these errors were encountered:
Hi @chriswzou ,
Thank you for catching this bug! You are definitely right that this is driven by the edge case when all perturbations are NP. We have commented out that line of code to avoid this.
Additionally, now we will throw a warning message to users if all the perturbations are NP and gv.list is empty.
Hi! Another issue - also happy to help fix this one if a quick PR is helpful. I was doing some testing of a single perturbation before starting a long run of them, and found that when perturbations all turn out to be NP, the
RunMixscale
function errors out.It looks like it might be coming from this line of the code, where the cell types are drawn from the name of the first perturbation added to
gv.list
. In cases wheregv.list
is empty however—which I think happens when all the perturbations are NP—I get asubscript out of bounds
error coming from trying to accessgv.list[[1]]
.One fix for this could be to derive the cell types from the
splits
variable.The text was updated successfully, but these errors were encountered: