Hi Steve First, very sorry that your mail stayed unanswered for so long. I had it on my to-do list, and the forgot about until Chris asked about the same issue on the list yesterday. So, to close this thread, too: On 2012-04-26 00:41, Steve Lianoglou wrote: > (maybe this is more appropriate for bioc-devel, but ...) > > Using R-2.15-patched, DESeq_1.9.4 > > DESeq isn't liking 1 row in my count data, and throws an error in the > `estimateAndFitDispersionsWithCoxReid` function. Specifically this > error: > > Error in glm.fit(mm, y, family = MASS::negative.binomial(initialGuess), : > NA/NaN/Inf in 'x' > > The count data looks like this, where w1,w2,w3 are replicates of experiment w: > > w1 w2 w3 x1 x2 x3 y1 y2 z1 z2 > 0 0 18 0 52 0 0 0 1 1 > > Ok -- it's weird, I'll grant you that. Still, instead of killing the > entire run (it's a little time consuming) I was curious if something > could be done about such troublesome count rows? > > For instance, in the `apply` loop we could wrap glm.fit into a > tryCatch() and just set the dispersion for this row as NA. When all is > said and done, perhaps emit a warning about "Can not estimate > dispersions for XX rows" and set their dispersion to `max(disps)`. You > could even set as an attribute of the object that is ultimately > returned the indices of the "bad" rows that the user could then remove > after wards. > > Would that be a reasonable thing to do? Very, you are right, a "try" should be in there. In fact, I had added a "try" fo 'fitNbinomGLMs' for the same reason and had just forgotten to to the same in 'estimateDispersions'. Now fixed in in DESeq version 1.8.3 (release) and 1.9.7 (devel). > Also, would you accept a patch to the > `estimateAndFitDispersionsWithCoxReid` that parallelizes it in a > similar way that DEXseq parallelizes some of its cpu-intensive bits? Yes, this is something else, I wanted to do since long, and have done in some internal test version but never carried over to trunk. SO, if you have a patch, might be helpful. Cheers Simon