e-valeur et arguments de getProbabilityAtLeastOrAbove() dans getMaximum
Lancer tout en double aura eu le mérite de faire apparaître un bug :
./vidjil -KAx 1 -z 0 -G germline/IGH data/Stanford_S22.fasta
./vidjil -KAx 1 -z 0 -G germline/IGH data/Stanford_S22.rc.fasta
et comparer les e-values (dans les .affects)
seed IGH SEG_+ 1.495965e-87 2.055996e-167/1.495965e-87 seed IGH SEG_- 2.866244e-79 2.866244e-79/5.924178e-170
3b3bc05b. Le calcul est bien mieux qu'avant, un getS() trainait sans raison. (Les tests ne changent pas... ces e-valeurs sont vraiment à un gros ordre de grandeur près !)
J'avoue ne pas être sûr du +1/-1, il faudra revérifier. En tout cas maintenant c'est symétrique par rapport au revcomp. Et je suis joueur, je pousse un test avec une vérif d'e-valeur (juste le début, c'est typiquement le truc qui peut louper sur all-slaves pour des raisons d'arrondi).
Pour les archives, toujours sur la première séquence de data/Stanford_S22(.rc).fasta :
Un décompte manuel des .affects donne :
- 66 k-mer V + 87 k-mer _ = 153 dans la partie gauche
- 28 k-mer J dans la partie droite
Les kms.results : found 0, value 66, pos 164-202, before 66/0, after 0/28 found 0, value 28, pos 39-77, before 28/0, after 0/66 (rc)
avec la modif +1/-1, on a (et c'est symétrique) at_least=66, length=165 (qui redevient bien n = 165 - 13 + 1 = 153 dans kmerstore.h:getProba()) at_least=28 length=40 (n = 28)
C'est du capillotracté, mais on n'a toujours pas la même e-valeur sur les deux brins : #> seed IGH SEG_+ 4.886466e-33 3.847709e-40/4.886465e-33 #> seed IGH SEG_- 4.885721e-33 4.885720e-33/3.847123e-40