Branche improve_representative
Ouah, joli boulot, je n'avais pas vu tout cela ! Pas testé, j'ai par contre feuilleté le code.
- Qualité : ce serait bien qu'on ajoute encore des tests (y compris pour les cas de trim de N à l'extérieur). Est-ce qu'il y a aussi des séquences réelles où maintenant c'est beacuoup mieux ?
- Vitesse : J'imagine qu'on est toujours globalement linéaire...
Enfin, en rebasant sur "sans-aho" ("improve_representative-sans-aho"), il ne manque que 5f724a6 : est-ce que cela peut se faire tout de même sans aho (et donc potentiellement mergeable cette semaine pour 2016.09 ?)
– Qualité : Pour les tests, oui c'est prévu. Les jeux problématiques de la Pitié sont des exemples où cela fonctionne nettement mieux (on passe d'une représentative d'une centaine de bases, à 400nt. Il reste quelques cas où la séquence représentative reste trop courte. Pour qu'elle soit de bonne longueur il faut diminuer le nombre de séquences auditionnées (passer de 2000 à 1000 voire 200) ce qui permet d'avoir une proportion plus importante de séquence de bonne qualité. Le problème est que si le clone possède 2000 reads, toutes les séquences seront auditionnées alors qu'il en existe certaines qui sont de mauvaise qualité et qui vont ajouter du bruit. – Vitesse, pas testé mais c'était prévu aussi. Ça doit rester dans le même ordre de grandeur normalement.
Le 5f724a6 : non cela ne peut pas se faire sans. Pour le coup on sortirait de longues représentatives, mais pas forcément significatives.
Hmm... curieux, cela ne passe pas sur mon système décadent :
In file included from germline.cpp:2: In file included from ./germline.h:8: ./kmerstore.h:384:10: error: no viable overloaded '=' seed = IKmerStore::seed; ~~~~ ^ ~~~~~~~~~~~~~~~~~~~
(En attendant cela passe sur rbx, je regarde fonctionnellement)
Avant la release, j'aimerais bien faire passer tout ça sur Jenkins (solution crade, mettre la branche sans-aho temporairement dans la conf du job Jenkins).
Ça compile pour moi avec g++4.9, g++5 et g++6 mais effectivement clang ne passe pas… Je ne comprends pas ce sont juste deux string…
Ça devrait être bon pour clang maintenant.
Merci, cher magicien. Je me suis amusé avec data/ambiguous_representative.fa. Cela marche bien pour l'extension (pas de N à l'extérieur, s'arrête au bon endroit). Par contre le premier N passe en A, c'est un effet de bord des k-mers ?
Avant la release, j'aimerais bien faire passer tout ça sur Jenkins
Oui. Ne t'embête pas avec Jenkins : Ce soir, je fais une séance de black git et je remets tout cela sur dev.
ambiguous_representative.fa: intéressant. Il y avait ce problème-là mais du coup je suis passé à un index pour chaque graîne (j'étais réticent au début, mais ça ne doit pas changer grand chose en terme de temps de calcul, un peu en espace mais on est sur de petites donnée). Je regarde à quoi c'est dû.
Tu m'autorises à tricher ? C'est à cause de la faible complexité de la séquence, on a deux fois la même graîne (--A--T--A--A--C--C--C--T--T--T) qui matche dans la séquence 2 et du coup lors du match « inattendu » cela couvre la position censée contenir le N.
Modifier une position permet d'augmenter la complexité et d'éviter le hit. J'ai commité un truc, tu en fais ce que tu veux.
Bien sûr, tricherie acceptée ! Merci.
(j'avais du d'ailleurs m'y reprendre à plusieurs fois avant de trouver des "noisy sequences" qui n'étendaient pas d'un nucléotide la représentative)