-
Notifications
You must be signed in to change notification settings - Fork 309
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
Adding k-mer and q-mer counting. #269
Conversation
All automated tests passed. |
val q = w.map(_._2) | ||
|
||
// reduce bases into string, reduce quality scores | ||
(b.map(_.toString).reduce(_ + _), q.reduce(_ * _)) |
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.
Is there an underflow / floating-point issue here? Is there a reason you're not just doing this computation in log-space? (i.e. omit the toSuccessProbability call above, and then q.reduce(_ + _) here instead?)
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.
There isn't an underflow issue when you're looking at short k-mers. If you have a 100-mer with all bases at Q20, your q weight for the q-mer is about 0.35.
Also, underflow isn't such an issue for q-mer counting. The goal is to get an expectation for the count of a k-mer, therefore q weights that underflow wouldn't have contributed much to the expectation anyways.
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.
Also, a 100-mer would be exceptionally long; current k-mer counting tools are pretty stoked about counting 20-mers.
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.
Fair enough -- okay, I'll merge as is.
See my question about log-scale computation, above (which might have some perf implications too, right?) If you address that and make sure this is rebased off of master, I'd be willing to merge this. |
@tdanford see my comments inline, I don't think there's a good reason to move to log scale. |
When you rebase, then, I will merge. |
@Argument(required = true, metaVar = "KMER_LENGTH", usage = "Length of k-mers", index = 2) | ||
var kmerLength: Int = 0 | ||
@Args4jOption(required = false, name = "-countQmers", usage = "Counts q-mers instead of k-mers.") | ||
var qmersNotKmers: Boolean = false |
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.
Naming this countQmers
is more clear.
Okay, if you make the changes suggested by Matt and rebase off of master, then I will hit the 'merge' button :-D |
All automated tests passed. |
Adding k-mer and q-mer counting.
Thanks, @fnothaft! |
This adds functions for k-mer and q-mer counting, which is necessary for error correction. Additionally, this adds commands that support counting k/q-mers from the CLI.
q-mers are quality score weighted k-mers, and are described in http://genomebiology.com/2010/11/11/R116/abstract.