Viterbi calculations in the NTI region are incorrect about linearham HOT 12 CLOSED

Re first point, it seems to me that we can do exactly the same as this:

except rather than doing matrix multiplication (e.g. in A_0 \cdot T) we take the max (rather than sum) of the component-wise products. We also record this index.

We also need to have someplace to store this information. We could have another Smooshish type that holds this information, does not have viterbi_ be the same as marginal_ as it is now.

I don't understand your second point-- the Viterbi path for the whole thing is the best path among those for the various chains, right?

from linearham.

Agree to the first point! Maybe even store it in NTInsertion class, but never initialize it if we want the marginal prob?

To your second comment, yes. But if we have tons of chains due to there being tons of SW matches, then doing a final max over all those wont be cheap? Its a minor thing if we have few matches per read (as our example files have). The sketch i have for how to do proper viterbi is not clean, so practically if you feel the number of SW matches is usually small most times then it shouldn't hurt to do that final max.

from linearham.

(Personally I'd rather not change so much of what we've already done for a proper viterbi if the gains aren't so high)

from linearham.

Agree to the first point! Maybe even store it in NTInsertion class, but never initialize it if we want the marginal prob?

Yep!

For your second point, I'm not sure what you are proposing as an alternate means of doing viterbi.

from linearham.

It would involve keeping track of not only max transition points but also max germline genes. Right now we only do it over transition points.

from linearham.

It seems to me that we can't get any more efficient than using the Chain structure, right? And at the end of the Chain inferences we will have the Viteri probabilities. From there it's just taking a max over a vector.

(Pretty sure I'm missing your point here...)

from linearham.

Its just that the max over all VDJ chains could be expensive because its max over (#V) * (#D) * (#J) elements, which could be costly depending on how many there are of V's, D's, J's, yeah?

from linearham.

Yes, but are you proposing a means of getting around that?

from linearham.

yes, but A) you seem ok with max'ing over all VDJ chains? and B) it might drastically change the code structure so do we care enough to do it?

from linearham.

You really have me curious, but I can guess what you're proposing by your comments above. It seems like for this round of coding we can focus on getting the existing branch merged and closing the issues as they stand, which AFAIK just requires more tests.

Then we can consider optimizing both the marginal and the viterbi calculations with more specialized code?

from linearham.

(BTW, partis will only serve I think 3 V's 5 D's and 4 J's, which is 60 combinations max)

from linearham.

we are going bayesian! viterbi unnecessary!

from linearham.