Closed ronlevine closed 8 years ago
hmmm. I think that the optimization of using a GenotypeLikelihoodsAllelePair overweighs the generalizability of multipliody.
is there a usecase for this?
is it needed for select variants? perhaps a non-diploid method could be added rather than changing the signature of this function.
Here's the usecase: https://github.com/broadinstitute/gatk/issues/1382 The plan is to keep the diploid optimization. Combinatorials with binomials is very compute intensive.
@yfarjoun Could you review the accompanying pull request? It should be ready momentarily.
It will not be this week, as I"m out conferencing in agbt. but if it can wait for next week then sure.
Y.
On Tue, Feb 9, 2016 at 9:40 AM, Ron Levine notifications@github.com wrote:
@yfarjoun https://github.com/yfarjoun Could you review the accompanying pull request? It should be ready momentarily.
— Reply to this email directly or view it on GitHub https://github.com/samtools/htsjdk/issues/437#issuecomment-181895468.
@yfarjoun Thanks. I'll look at your comments next week while I'm in Miami.
I think this should be closed.
GenotypeLikelihoodsAllelePair GenotypeLikelihoods.getAllelePair(final int PLindex)
returns the cached alleles corresponding to the PLindex. This cache is diploid because the method that initializes it,GenotypeLikelihoodsAllelePair[] GenotypeLikelihoods.calculatePLcache(final int altAlleles)
, uses a diploid number of likelihoods (numLikelihoods(1 + altAlleles, 2)
) and adds an allele pair each PLindex, instead of the ploidy number of allele indices. If the methods are generalized, they should returnArrayList<Integer>
instead ofGenotypeLikelihoodsAllelePair
.