|
|
|
@@ -586,3 +586,497 @@ course dans `obiiter.IBioSequence.RebatchBySize` (appelée par `CLIReadBioSequen
|
|
|
|
|
réaffectait la variable capturée `iterator` (`iterator = iterator.SortBatches()`) pendant que la fonction
|
|
|
|
|
appelante lisait `iterator.IsPaired()`. Corrigé avec une variable locale (`sorted`), comportement inchangé ;
|
|
|
|
|
les tests de `obiiter`, `obiformats` et `obitools/...` passent.
|
|
|
|
|
|
|
|
|
|
### 16 bis. Suppression de `taxonomic_path` après extraction (2026-11-03, demande de l'utilisateur)
|
|
|
|
|
|
|
|
|
|
Une fois la taxonomie construite, l'attribut `taxonomic_path` (liste d'une vingtaine de chaînes par
|
|
|
|
|
séquence) ne sert plus : la recherche lit les taxons par le `taxid`. Il est supprimé dans les trois
|
|
|
|
|
chemins de lecture (`obiprimers.go`) : fichiers (worker `obiseq.AnnotatorToSeqWorker` sur la seconde
|
|
|
|
|
passe), entrée standard (en place sur la tranche gardée en mémoire, avant de la réémettre) et `-t` donné
|
|
|
|
|
avec un fichier annoté (les chemins sont inutiles). Réutilisation : `AnnotatorToSeqWorker` et
|
|
|
|
|
`BioSequence.DeleteAttribute` existants ; seul ajout partagé : la constante
|
|
|
|
|
`obiseq.TaxonomicPathAttribute`, utilisée par `SetPath`/`Path` à la place du littéral. Test :
|
|
|
|
|
`TestTaxonomicPathIsDroppedAfterExtraction` (le chemin disparaît, le `taxid` reste).
|
|
|
|
|
|
|
|
|
|
**Mesures, sans gain visible sur le pic de mémoire du processus** :
|
|
|
|
|
- tas réellement libéré (7 822 séquences, 131 Mb de bases, `GC` forcé, tranche gardée vivante) :
|
|
|
|
|
**19,2 Mo sur 193,7 Mo (9,9 %), 2,46 Ko par séquence**. Un premier essai donnait « 99,9 % » : il était faux
|
|
|
|
|
(la tranche n'était plus référencée, donc toutes les séquences avaient été libérées) ;
|
|
|
|
|
- pic de mémoire du processus (entrée standard, 8 mesures entrelacées chacune) : médiane **1 334 Mo avant,
|
|
|
|
|
1 346 Mo après**, dispersion > 250 Mo : aucune différence détectable.
|
|
|
|
|
|
|
|
|
|
Interprétation : le gain est réel mais de l'ordre de 10 % des séquences gardées, soit ~1 % du pic ici ; il
|
|
|
|
|
deviendrait important sur de très grandes bases (à 2,46 Ko par séquence, ~2,5 Go pour un million de
|
|
|
|
|
séquences). **Le pic de 1,3 Go est sans commune mesure avec les 194 Mo de séquences gardées** : l'essentiel
|
|
|
|
|
du pic vient d'ailleurs (lecture/analyse des 131 Mb du FASTA, retard du ramasse-miettes : `GOGC=25` avait
|
|
|
|
|
fait passer le pic de 2,82 à 1,98 Go). C'est la piste à analyser pour la mémoire.
|
|
|
|
|
|
|
|
|
|
## 17. Validation avec contre-exemples : `-r 7953 -i 1` (2026-11-03)
|
|
|
|
|
|
|
|
|
|
Premier cas **avec contre-exemples** comparé à ecoPrimers (la section 1 de l'inventaire : jusque-là tous les
|
|
|
|
|
jeux de référence avaient 0 contre-exemple). Les 325 Cyprinidae sont les exemples (`-r 7953`) et toutes les
|
|
|
|
|
autres séquences de la base (7 497, 7 387 espèces) sont des contre-exemples (`-i 1`, la racine). Paramètres :
|
|
|
|
|
`-e 3 -3 2 -l 30 -L 150 -c`. (« -I 1 » demandé : ecoPrimers n'a pas d'option `-I` ; sa boucle `getopt`
|
|
|
|
|
ignore silencieusement une option inconnue, donc c'était `-i`.)
|
|
|
|
|
|
|
|
|
|
| | ecoPrimers | obiprimers |
|
|
|
|
|
|---|---|---|
|
|
|
|
|
| exemples / contre-exemples | 325 (316 esp.) / 7 497 (7 387 esp.) | identique |
|
|
|
|
|
| quorum de contre-exemples | 749 / 7 497 | identique |
|
|
|
|
|
| paires retenues | **173** | **173** |
|
|
|
|
|
| temps | **2 728 s (45,5 min)**, 1 cœur | **1,9 s**, 16 workers |
|
|
|
|
|
| pic mémoire | 756 Mo | 781 Mo (taxonomie embarquée) |
|
|
|
|
|
|
|
|
|
|
**Les deux tables sont identiques sur tous les champs** (173/173 paires, 0 différence : amorces, drapeaux
|
|
|
|
|
good, séquences et taxons amplifiés côté exemples ET contre-exemples, Yule, Bc, Bs, longueurs, GC, Tm).
|
|
|
|
|
Répartition des drapeaux good : 97 `bG` et 76 `Gb` (une seule amorce good par paire, comme attendu avec
|
|
|
|
|
des contre-exemples aussi nombreux) ; contre-exemples amplifiés par paire : de 264 à 513 séquences.
|
|
|
|
|
Notre journal : 6 850 691 occurrences approchées (contre 227 549 sans contre-exemples), 1 200 amorces
|
|
|
|
|
conservées dont **14 good**, 2 037 paires candidates, 200 amplifiant assez d'exemples, 173 retenues
|
|
|
|
|
(ecoPrimers : « Total pair count 2050 », écart de 13 attendu : il a un mot strict de plus, section 10).
|
|
|
|
|
|
|
|
|
|
Fixé dans `testdata/ecoprimers_Cyprinidae_I1.pairs.tsv` ; test opt-in `TestCounterExamplesAgainstEcoPrimers`.
|
|
|
|
|
Cela couvre désormais : quorum de faux positifs, drapeau good avec contre-exemples, comptes de taxons
|
|
|
|
|
contre-exemples. Reste à comparer (inventaire section 1) : séquences linéaires, `--rank` autre qu'espèce,
|
|
|
|
|
`-e 0`, autres `-e` / `-O` / quorums, et `-E` (exception).
|
|
|
|
|
|
|
|
|
|
## 18. Validation par variantes d'options, Cyprinidae `-r 7953` (2026-11-03)
|
|
|
|
|
|
|
|
|
|
16 exécutions d'ecoPrimers lancées en parallèle (1 cœur chacune, 2 à 6 minutes sans contre-exemples),
|
|
|
|
|
comparées ligne à ligne (multi-ensembles de lignes, car des paires d'amorces AT répétées existent des deux
|
|
|
|
|
côtés) à `obiprimers` avec les options équivalentes. Scripts jetables : `/tmp/run_val*.sh`,
|
|
|
|
|
`/tmp/run_mine.sh`, `/tmp/compare_val.py` (non versionnés).
|
|
|
|
|
|
|
|
|
|
**Identiques sur toutes les lignes et tous les champs** :
|
|
|
|
|
|
|
|
|
|
| Variante | Lignes |
|
|
|
|
|
|---|---|
|
|
|
|
|
| séquences linéaires (sans `-c`) | 3 448 |
|
|
|
|
|
| `-e 1` | 2 031 |
|
|
|
|
|
| `-e 5` | 4 080 |
|
|
|
|
|
| `-O 20` | 2 288 |
|
|
|
|
|
| `-O 25` | 867 |
|
|
|
|
|
| `-q 0.8 -s 0.95` | 1 110 |
|
|
|
|
|
| `-q 0.5 -s 0.8` | 13 941 |
|
|
|
|
|
| `-3 0` | 5 405 |
|
|
|
|
|
| `-3 4` | 2 262 |
|
|
|
|
|
| `-l 10 -L 80` | 223 |
|
|
|
|
|
| `-E 7954` (Danio, 5 contre-exemples hors des exemples) | 11 |
|
|
|
|
|
| `-E 7954 -x 0.05 -s 0.8` | 16 |
|
|
|
|
|
| `-E 84644 -x 0.95` (Labeo : 304 exemples, 21 contre-exemples dans les exemples) | 54 |
|
|
|
|
|
|
|
|
|
|
`-E 84644` seul et `-E 84644 -x 0.05 -s 0.8` donnent 0 paire des deux côtés : identiques mais sans valeur,
|
|
|
|
|
les Labeo étant amplifiés par toutes les amorces conservées ; d'où la variante `-x 0.95`.
|
|
|
|
|
|
|
|
|
|
**`--rank genus` et `-T 0.3` : différents, mais entièrement expliqués** (par mesure) :
|
|
|
|
|
1. **118 et 119 paires seulement chez ecoPrimers** : toutes contiennent le mot strict en trop d'ecoPrimers
|
|
|
|
|
`TTTATGAAAACAAATAAA` (section 10 : présent dans 225 séquences, quorum 227). Aucune des paires absentes
|
|
|
|
|
ne l'ignore ; aucune ligne des variantes identiques ne le contient. Leurs comptes d'exemples vont de 294
|
|
|
|
|
à 325 : l'hypothèse « effet de seuil à 293 » avait été testée et réfutée.
|
|
|
|
|
2. **52 et 65 lignes avec une séquence d'exemple de plus chez ecoPrimers** (exactement +1 exemple, +0
|
|
|
|
|
contre-exemple à chaque fois) : l'artefact du `N` dans la vérification du 3' (section 12).
|
|
|
|
|
3. **9 écarts de Tm minimale** (mêmes comptes de séquences) : ecoPrimers décode les sites contenant une
|
|
|
|
|
base ambiguë avec le même registre à décalage ; nous ignorons ces sites (section 12).
|
|
|
|
|
Preuve : un binaire temporaire émulant exactement `extractSite` (3' et sites de Tm), sources restaurées
|
|
|
|
|
ensuite (diff identique aux sauvegardes), supprime **toutes** les différences de champs ; ne restent que
|
|
|
|
|
les 118/119 paires du mot en trop.
|
|
|
|
|
|
|
|
|
|
## 19. Décisions de l'utilisateur et options `-b`, `-M`, `-k` (2026-11-03)
|
|
|
|
|
|
|
|
|
|
- **Taxonomie embarquée : extraction stricte** (comme `obitag`) : comportement actuel conservé, rien à changer.
|
|
|
|
|
- **Test instable corrigé** : `obiutils.Set.String()` parcourait une map Go (ordre aléatoire) ; elle trie
|
|
|
|
|
désormais ses membres (entiers, flottants et chaînes par valeur, y compris types nommés ; repli sur la forme
|
|
|
|
|
texte pour les autres types). `Members()` est inchangé. Test `TestSetStringIsStable` ; `TestSetString` passe
|
|
|
|
|
200 fois de suite (il échouait ~4 fois sur 6) et tout le paquet passe.
|
|
|
|
|
- **`-b`, `-M`, `-k`, `-p`** : lus dans `PrimerSets.c` (voir ci-dessous) ; porter ou abandonner : à trancher.
|
|
|
|
|
|
|
|
|
|
### Ce que sont ces options dans ecoPrimers (lu dans le code)
|
|
|
|
|
|
|
|
|
|
Un « lien » entre deux paires = le nombre de séquences que **les deux** paires identifient sans ambiguïté
|
|
|
|
|
(`wellIdentifiedSeqs[k] == 1` pour les deux). Le but est de choisir des paires complémentaires (plusieurs
|
|
|
|
|
marqueurs) : peu de liens = les paires identifient des taxons différents.
|
|
|
|
|
- `-b` : filtre la liste finale des paires avec `primers_changeSortedArray` (puis réimprime). Une paire est
|
|
|
|
|
gardée s'il existe une autre paire avec laquelle elle a au plus 5 liens ou plus de la moitié du plus petit
|
|
|
|
|
nombre de taxons identifiés ; elle n'est écartée que si, avec **toutes** les autres, ses liens sont entre 6
|
|
|
|
|
et cette moitié. Règle heuristique sans justification dans le code.
|
|
|
|
|
- `-M` : seuil absolu de liens (nom trompeur : « percent » mais utilisé comme un nombre). Quand il est donné,
|
|
|
|
|
la boucle contient un `break` inconditionnel : chaque paire n'est comparée qu'à la **première** autre paire
|
|
|
|
|
de la liste, donc le filtre ne fait pas ce qu'il annonce.
|
|
|
|
|
- `-k` : n'est lu que par `ok_to_add` (construction d'ensembles d'amorces), inatteignable puisque `-p` est
|
|
|
|
|
désactivé : option morte.
|
|
|
|
|
- `-p` : sa ligne d'affectation est commentée dans `ecoprimer.c` ; elle ne fait rien. Le code d'ensembles
|
|
|
|
|
associé (glouton, recuit simulé, tabou, force brute) n'est jamais exécuté.
|
|
|
|
|
- `primers_filterWithGivenLinks` et `primers_graph_graphviz` ne sont jamais appelées.
|
|
|
|
|
Dépendance technique d'un éventuel portage : il faudrait garder, pour chaque paire retenue, l'ensemble des
|
|
|
|
|
séquences qu'elle identifie (aujourd'hui seule leur nombre de taxons est conservé).
|
|
|
|
|
|
|
|
|
|
## 20. Le problème multi-marqueurs : spécification (discussion du 2026-11-03)
|
|
|
|
|
|
|
|
|
|
**Statut : spécification en cours, aucun code écrit.** Décisions de l'utilisateur ci-dessous ; les points
|
|
|
|
|
marqués « proposition » ou « question ouverte » sont de moi et n'ont pas été validés.
|
|
|
|
|
|
|
|
|
|
### 20.1 Origine de `-b`, `-M`, `-k`, `-p` : abandonnées
|
|
|
|
|
|
|
|
|
|
Ces options sont des pistes explorées pendant la thèse de Tiayyba Riaz (auteur de l'article), il y a une
|
|
|
|
|
quinzaine d'années, jamais menées à terme : le problème était mal posé. L'utilisateur avait oublié qu'elles
|
|
|
|
|
traînaient dans le code. **Décision : elles ne sont pas portées** (confirmant l'analyse de la section 19 : deux
|
|
|
|
|
options mortes, une buguée, un filtre heuristique non justifié).
|
|
|
|
|
|
|
|
|
|
Le modèle de la thèse : chaque paire d'amorces couvre et reconnaît une partie des espèces, avec un
|
|
|
|
|
recouvrement partiel entre paires ; on cherche la meilleure combinaison (graphe de « liens », glouton, recuit
|
|
|
|
|
simulé, tabou, force brute). Ce modèle est quasi inapplicable : un recouvrement d'espèces entre deux paires
|
|
|
|
|
visant des clades différents signifie qu'une amorce est partagée entre ces clades, donc que le recouvrement
|
|
|
|
|
est presque toujours **complet**. Les ensembles de couverture sont emboîtés ou disjoints par clade.
|
|
|
|
|
|
|
|
|
|
### 20.2 Formulation correcte
|
|
|
|
|
|
|
|
|
|
But : un ensemble de marqueurs (un multiplex) qui, ensemble, discriminent un maximum d'espèces.
|
|
|
|
|
Structure :
|
|
|
|
|
1. **une paire de base** qui couvre la totalité du groupe visé (Bc proche de 1) ;
|
|
|
|
|
2. **une collection de paires spécialisées**, chacune sur un clade que les paires précédentes résolvent mal.
|
|
|
|
|
|
|
|
|
|
### 20.3 Réponses de l'utilisateur
|
|
|
|
|
|
|
|
|
|
1. **Granularité des clades à raffiner : elle dépend du nombre de paires autorisées dans le multiplex.**
|
|
|
|
|
Avec 2 paires : une paire générique + une seule paire spécialisée, placée assez haut dans la taxonomie,
|
|
|
|
|
autour d'un gros groupe très mal résolu (celle qui récupère le plus d'espèces). Avec 30 paires : on peut
|
|
|
|
|
éclater presque chaque famille ou chaque genre mal résolu.
|
|
|
|
|
2. **Éviter d'amplifier les autres clades : pas par défaut, mais une option.** Elle permet de concentrer
|
|
|
|
|
l'effort d'amplification sur le clade d'intérêt sans le disperser, surtout s'il est sous-représenté dans la
|
|
|
|
|
matrice d'ADN.
|
|
|
|
|
3. **Critère de résolution : une espèce est résolue si au moins un marqueur la résout.**
|
|
|
|
|
4. **Budget : deux formulations possibles, non tranchées** (maximiser les espèces résolues avec au plus K
|
|
|
|
|
paires ; ou minimiser le nombre de paires pour atteindre un taux donné).
|
|
|
|
|
5. **La paire de base est choisie d'abord**, ce qui élimine les espèces bien reconnues ; on raisonne ensuite
|
|
|
|
|
sur ce qui reste (glouton hiérarchique).
|
|
|
|
|
|
|
|
|
|
### 20.4 Ce que cela implique (propositions, à valider)
|
|
|
|
|
|
|
|
|
|
- **Algorithme glouton hiérarchique** : paire de base sur tout le groupe (tri Bc puis Bs, comme le mode A) ;
|
|
|
|
|
puis, tant que le budget le permet, parmi les nœuds de la taxonomie contenant des espèces non résolues,
|
|
|
|
|
choisir la paire spécialisée au **plus grand gain marginal** (espèces nouvellement résolues). La
|
|
|
|
|
granularité exigée en 20.3-1 en découle sans règle séparée : un petit budget favorise les nœuds hauts, un
|
|
|
|
|
grand budget finit par les genres. Les deux formulations du budget (20.3-4) sont le même gain marginal avec
|
|
|
|
|
deux conditions d'arrêt (K paires atteint, ou taux visé atteint) : le choix n'a pas à être tranché pour
|
|
|
|
|
écrire la boucle.
|
|
|
|
|
- **Réutilisation** : le mode A avec `-r <clade>` produit déjà les paires conservées dans un clade et leur Bs.
|
|
|
|
|
Le mode A étant rapide (de 2 à 3 s pour Teleostei), faire une recherche par clade candidat est envisageable ;
|
|
|
|
|
le corpus devrait alors être chargé une seule fois et la sélection exemples/contre-exemples refaite en
|
|
|
|
|
mémoire pour chaque clade (aujourd'hui `LoadCorpus` relit les fichiers).
|
|
|
|
|
- **Manque 1 : les ensembles d'espèces résolues.** Aujourd'hui `PairStats` ne garde que des nombres
|
|
|
|
|
(`Identified`, `ExampleTaxa`). Il faut, pour chaque paire, l'ensemble des taxons identifiés et les classes
|
|
|
|
|
de taxons partageant un amplicon (même besoin qu'un portage de `-b`).
|
|
|
|
|
- **Question ouverte (moi) : relativement à quel ensemble une espèce est-elle « résolue » par un spécialiste
|
|
|
|
|
qui peut amplifier d'autres clades (20.3-2) ?** Le Bs actuel ne juge l'unicité de l'amplicon que parmi les
|
|
|
|
|
exemples. Si le spécialiste amplifie aussi des espèces extérieures au clade, un amplicon partagé avec un
|
|
|
|
|
extérieur ne permet pas d'identifier l'espèce dans un échantillon réel. Je propose de juger l'unicité sur
|
|
|
|
|
**tout ce que la paire amplifie dans la base de référence**. Cela demande un troisième rôle de séquence,
|
|
|
|
|
« contexte » : non exigée amplifiée, non pénalisée, mais comptée dans le partage d'amplicons.
|
|
|
|
|
- **Lien avec la voie B** : avec l'option « éviter les autres clades » (20.3-2), les voisins deviennent des
|
|
|
|
|
contre-exemples ; sans elle, ils sont du contexte. La voie B (amorces spécifiques d'une espèce ou de
|
|
|
|
|
quelques espèces proches) et l'étape de spécialisation ressemblent donc beaucoup : je propose de les
|
|
|
|
|
spécifier ensemble, comme un seul mécanisme avec une option d'exclusion.
|
|
|
|
|
- **Non abordé, à demander** : compatibilité des amorces d'un même multiplex (Tm voisines, absence de
|
|
|
|
|
dimères entre amorces de paires différentes). `obithermo` fournit déjà les Tm.
|
|
|
|
|
- **Sortie** : un ensemble ordonné de paires avec, pour chacune, les espèces qu'elle ajoute (gain marginal) ;
|
|
|
|
|
la courbe cumulée des espèces résolues en fonction du nombre de paires répond aux deux formulations du
|
|
|
|
|
budget.
|
|
|
|
|
|
|
|
|
|
### 20.5 Prochaines étapes
|
|
|
|
|
|
|
|
|
|
Pas de code avant accord sur 20.4. À trancher : (a) le jugement d'unicité (tout ce qui est amplifié, ou
|
|
|
|
|
seulement le clade), donc le rôle « contexte » ; (b) si les voies B et de spécialisation sont spécifiées
|
|
|
|
|
ensemble ; (c) les contraintes de multiplex. Le reste de l'inventaire du mode A (validation `-e 0`, nettoyage,
|
|
|
|
|
mémoire, tests shell, documentation) est indépendant et peut avancer.
|
|
|
|
|
|
|
|
|
|
## 21. Suite de la spécification : résolution, voie B, optimisation de Tm (2026-11-03)
|
|
|
|
|
|
|
|
|
|
**Statut : spécification, aucun code.** « Décision » = réponse de l'utilisateur ; « Proposition » et
|
|
|
|
|
« Question » = de moi, non validées.
|
|
|
|
|
|
|
|
|
|
### 21.1 Décisions
|
|
|
|
|
|
|
|
|
|
1. **Une espèce est résolue par rapport à tout ce qui est amplifié**, dans le clade cible **et** dans le clade
|
|
|
|
|
voisin non cible. Confirme le jugement d'unicité sur tout ce que la paire amplifie dans la référence.
|
|
|
|
|
2. **La voie B doit être spécifiée complètement** avant tout code (et avec la spécialisation, 20.4).
|
|
|
|
|
3. **Tm** : idéalement oui, des Tm voisines entre amorces. Aujourd'hui la longueur est fixée et la Tm subie.
|
|
|
|
|
Idée de l'utilisateur : **fixer la Tm et optimiser la longueur à la fin pour équilibrer les Tm**, et cela
|
|
|
|
|
**pour n'importe quelle paire**. Ajouter à `obiprimers` une **phase d'optimisation de Tm** avec deux
|
|
|
|
|
paramètres : **un écart de Tm maximal entre les deux amorces** et **une Tm cible pour les paires**.
|
|
|
|
|
|
|
|
|
|
### 21.2 Conséquence de 21.1-1 : quatre rôles de séquences (proposition)
|
|
|
|
|
|
|
|
|
|
| Rôle | Exigence sur l'amplification | Compte dans l'unicité des amplicons |
|
|
|
|
|
|---|---|---|
|
|
|
|
|
| Exemple | doit être amplifiée (quorum de sensibilité) | oui |
|
|
|
|
|
| Contre-exemple | ne doit pas l'être (quorum de faux positifs) | **oui, si amplifiée** |
|
|
|
|
|
| Contexte | libre, aucune pénalité | **oui, si amplifiée** |
|
|
|
|
|
| Ignorée | sans objet | non |
|
|
|
|
|
|
|
|
|
|
Le rôle « contexte » est nouveau (aujourd'hui : exemple, contre-exemple, ignorée). L'option « éviter les autres
|
|
|
|
|
clades » (20.3-2) transforme simplement leurs séquences de contexte en contre-exemples.
|
|
|
|
|
**Écart avec ecoPrimers à noter** : le Bs d'ecoPrimers ne juge l'unicité que parmi les exemples, même quand des
|
|
|
|
|
contre-exemples sont amplifiés. Proposition : **garder le Bs d'ecoPrimers inchangé** (c'est ce qui reproduit
|
|
|
|
|
les tables de référence) et ajouter un second indice calculé sur tout ce qui est amplifié (nom à choisir,
|
|
|
|
|
p. ex. `bs_all`), qui sert à la sélection multi-marqueurs ; il coïncide avec `bs` quand il n'y a ni
|
|
|
|
|
contre-exemple amplifié ni contexte.
|
|
|
|
|
|
|
|
|
|
### 21.3 Optimisation de Tm (proposition, paramètres de l'utilisateur)
|
|
|
|
|
|
|
|
|
|
- **Paramètres** : `Tm cible` et `écart de Tm maximal`. Proposition d'interprétation : la cible porte sur la
|
|
|
|
|
**moyenne des deux amorces** et l'écart borne leur différence, ce qui revient à imposer à chaque amorce
|
|
|
|
|
`cible ± écart/2`.
|
|
|
|
|
- **Où** : phase **après** la sélection des paires, sur chaque paire retenue : choisir les longueurs
|
|
|
|
|
`(L1, L2)` des deux amorces satisfaisant la cible et l'écart.
|
|
|
|
|
- **Ce qui rend la phase possible** : raccourcir une amorce **par son extrémité 5'** ne peut que conserver ou
|
|
|
|
|
réduire ses erreurs sur chaque site (c'est une sous-chaîne), donc la sensibilité est conservée. Allonger
|
|
|
|
|
par le 5' demande de **revérifier** les sites. Raccourcir fait en revanche perdre de la spécificité
|
|
|
|
|
(l'amorce raccourcie peut s'apparier ailleurs), d'où la nécessité de **réévaluer la paire** (sensibilité,
|
|
|
|
|
faux positifs, Bc, Bs, Tm) après chaque changement de longueur.
|
|
|
|
|
- **Réutilisation** : `obithermo` (Tm, Tm minimale), `MatchWords` et `FindPairs` sur une poignée de mots :
|
|
|
|
|
le coût est celui d'une évaluation par variante de longueur et par paire.
|
|
|
|
|
- **Intérêt pour le multiplex** : une Tm cible commune à toutes les paires d'un ensemble les rend compatibles
|
|
|
|
|
par construction.
|
|
|
|
|
- **Questions** : (a) la cible porte-t-elle sur la Tm de l'appariement parfait ou sur la Tm minimale sur les
|
|
|
|
|
sites (la pire), ou sur une valeur intermédiaire ? (b) bornes de longueur [Lmin, Lmax] ? Le mot actuel est
|
|
|
|
|
limité à 31 bases (codage 2 bits sur 64). (c) extension et raccourcissement seulement par le 5', en gardant
|
|
|
|
|
l'ancrage 3' ? (d) « pour n'importe quelle paire » : phase intégrée à la recherche, ou aussi outil
|
|
|
|
|
indépendant appliqué à des amorces fournies par l'utilisateur ? (e) une paire dont la Tm ne peut pas être
|
|
|
|
|
satisfaite dans les bornes : écartée ou signalée ?
|
|
|
|
|
|
|
|
|
|
### 21.4 Voie B : esquisse de spécification (proposition)
|
|
|
|
|
|
|
|
|
|
**But.** Une paire qui amplifie les cibles T (une espèce, ou quelques espèces très proches) et, autant que
|
|
|
|
|
possible, aucun de leurs voisins non cibles C. Facteur de conception : l'espace de recherche est élagué en
|
|
|
|
|
se concentrant sur les régions **non conservées** (celles où T diffère de C), l'inverse du mode A.
|
|
|
|
|
|
|
|
|
|
**Rôles.** T = exemples ; C = contre-exemples (voisins à ne pas amplifier) ; le reste, contexte ou ignoré.
|
|
|
|
|
|
|
|
|
|
**Constat.** Le pipeline actuel fait déjà fonctionner un cas voie B de façon naïve (`-r 8028 -i 8015`, *Salmo*
|
|
|
|
|
contre les autres Salmonidae : 7 exemples, 76 contre-exemples, 15 534 mots stricts), mais sans élagage, et le
|
|
|
|
|
critère « un quorum de faux positifs de 10 % » y est trop permissif pour une amorce spécifique.
|
|
|
|
|
|
|
|
|
|
**Principe d'une paire spécifique.** Une paire n'amplifie un voisin que si **ses deux amorces** s'y apparient.
|
|
|
|
|
Il suffit donc d'**une amorce spécifique** (loin de tous les sites de C) et d'une **amorce partenaire**
|
|
|
|
|
quelconque et conservée dans T, à distance d'amplicon permise. Les candidats se génèrent ainsi : mots de T
|
|
|
|
|
(quorum de T) dont aucun site à <= `e_exclusion` erreurs n'existe dans C (au-delà du quorum de faux
|
|
|
|
|
positifs) ; puis le partenaire dans la fenêtre d'amplicon de chaque occurrence dans T.
|
|
|
|
|
|
|
|
|
|
**Deux tolérances (proposition).** `-e` (sensibilité sur T) et une tolérance d'exclusion **`e_exclusion`** sur C,
|
|
|
|
|
éventuellement plus grande : un voisin est « amplifié » s'il s'apparie à `e_exclusion` erreurs ou moins. Cela
|
|
|
|
|
donne une marge de sécurité sans dégrader la sensibilité sur T.
|
|
|
|
|
|
|
|
|
|
**Score de marge (proposition).** Pour une amorce : nombre minimal d'erreurs d'un site de C ; pour la paire :
|
|
|
|
|
la meilleure des deux amorces (un voisin n'est amplifié que si les deux s'apparient), avec un poids
|
|
|
|
|
particulier pour les erreurs proches du 3'. Il compléterait Yule x Bs pour classer.
|
|
|
|
|
|
|
|
|
|
**Sortie.** Colonnes du mode A plus la marge des deux amorces.
|
|
|
|
|
|
|
|
|
|
**Échelle (à prévoir).** Pour T = un génome, le nombre de mots candidats est celui des positions du génome
|
|
|
|
|
(16 000 pour une mitochondrie, des millions pour une bactérie) : l'index de graines (`MatchWords`) indexe les
|
|
|
|
|
**mots** et balaie le texte de C ; pour des millions de mots il faudra les traiter par lots, chacun balayant C
|
|
|
|
|
une fois. À dimensionner selon l'usage visé.
|
|
|
|
|
|
|
|
|
|
**Questions pour finaliser.**
|
|
|
|
|
1. **Exclusion stricte ou marge** : une paire est-elle admise seulement si elle n'amplifie aucun voisin à
|
|
|
|
|
`e_exclusion` erreurs, ou classe-t-on par marge sans seuil dur ? Faut-il une contrainte particulière sur
|
|
|
|
|
les 3' derniers nucléotides des voisins (au moins une erreur dans les 5 dernières bases) ?
|
|
|
|
|
2. **Tailles typiques** de T et de C (une espèce avec combien de séquences ? voisins = un genre, une famille,
|
|
|
|
|
toute la base de 8 000 génomes mitochondriaux, des génomes entiers de bactéries ?).
|
|
|
|
|
3. **Type de séquences** : génomes organellaires entiers (comme le tutoriel), loci courts, génomes complets ?
|
|
|
|
|
4. **Plusieurs cibles** (quelques espèces proches) : amplifier le groupe sans les distinguer (détection de
|
|
|
|
|
groupe), ou les amplifier et les **résoudre** entre elles (Bs au sein de T, comme la spécialisation) ?
|
|
|
|
|
5. **Une amorce spécifique + une générale** est-il acceptable, ou les deux amorces doivent-elles être
|
|
|
|
|
spécifiques ?
|
|
|
|
|
6. **Sensibilité sur T** : quorum comme en mode A (0,9), ou toutes les séquences de T (intra-spécifique) ?
|
|
|
|
|
|
|
|
|
|
### 21.5 Travaux préalables communs (sans les engager)
|
|
|
|
|
|
|
|
|
|
Rôle « contexte » ; indice de résolution sur tout ce qui est amplifié ; ensembles d'espèces résolues par
|
|
|
|
|
paire ; corpus chargé une seule fois et sélection refaite en mémoire ; réévaluation d'une paire pour des
|
|
|
|
|
longueurs d'amorces variables ; marge d'une amorce (erreurs minimales sur C).
|
|
|
|
|
|
|
|
|
|
## 22. Réponses de l'utilisateur sur la résolution et la Tm (2026-11-03)
|
|
|
|
|
|
|
|
|
|
**Statut : spécification, aucun code.** La voie B attend les réponses de l'utilisateur (« encore un peu »).
|
|
|
|
|
|
|
|
|
|
### 22.1 Redéfinir Bs : oui (décision de principe, détails à confirmer)
|
|
|
|
|
|
|
|
|
|
Question de l'utilisateur : ecoPrimers calcule Bs sur les seules séquences amplifiées parce que ce sont les
|
|
|
|
|
seules chargées en mémoire ; ne vaudrait-il pas mieux **charger tout le monde, chercher les amorces
|
|
|
|
|
seulement dans une sélection, et tester sur tout le monde** ? Réponse : **oui**, et cela redéfinit Bs. Trois
|
|
|
|
|
populations distinctes :
|
|
|
|
|
|
|
|
|
|
| Population | Sert à |
|
|
|
|
|
|---|---|
|
|
|
|
|
| exemples (sélection de recherche) | générer les mots conservés ; sensibilité ; dénominateur de Bc et de Bs |
|
|
|
|
|
| contre-exemples | quorum de faux positifs |
|
|
|
|
|
| **tout le monde** (population d'évaluation) | juger l'unicité des amplicons : une espèce exemple est résolue si son amplicon n'est partagé avec aucun autre taxon amplifié, où qu'il soit dans la base |
|
|
|
|
|
|
|
|
|
|
Proposition de définition : `Bs = espèces exemples dont l'amplicon est unique parmi tous les taxons amplifiés de
|
|
|
|
|
la population d'évaluation / espèces exemples amplifiées`. Elle coïncide avec le Bs d'ecoPrimers quand la
|
|
|
|
|
population d'évaluation est la sélection (aucun contre-exemple ni contexte amplifié). **Piège à ne pas
|
|
|
|
|
oublier** : avec `-i 1` (validation de la section 17) le Bs d'ecoPrimers ignore les amplicons des
|
|
|
|
|
contre-exemples amplifiés ; la nouvelle définition changera donc ces valeurs. Pour garder les tests de
|
|
|
|
|
non-régression, proposition : conserver aussi le Bs d'ecoPrimers dans une colonne à part (p. ex.
|
|
|
|
|
`bs_examples`) et définir `bs` comme le nouvel indice ; à confirmer. Colonne informative à ajouter :
|
|
|
|
|
nombre de taxons hors exemples amplifiés.
|
|
|
|
|
|
|
|
|
|
**Mémoire (proposition)** : charger tout le monde n'est pas nécessaire pour un passage simple. Après la
|
|
|
|
|
recherche (sur la sélection, en mémoire), un **passage d'évaluation en flux** relit la base entière avec les
|
|
|
|
|
seules amorces des paires retenues (quelques centaines de mots : `MatchWords` en 0,04 s pour 65 Mb) et ne
|
|
|
|
|
conserve que, par paire, un hash d'amplicon et un taxon par séquence amplifiée, jamais les séquences. Coût :
|
|
|
|
|
une relecture du fichier (comme la double lecture de la taxonomie embarquée). Pour la sélection multi-marqueurs
|
|
|
|
|
(évaluations répétées par clade), une population d'évaluation **en mémoire sous forme compacte** (2 bits par
|
|
|
|
|
base, soit ~33 Mo pour les 131 Mb du tutoriel) serait préférable. À trancher à la spécification de la
|
|
|
|
|
sélection multi-marqueurs.
|
|
|
|
|
|
|
|
|
|
### 22.2 Longueur des amorces : 61 nucléotides (question de l'utilisateur)
|
|
|
|
|
|
|
|
|
|
L'utilisateur rappelle qu'agrep avait été réimplémenté en 64 bits pour des amorces jusqu'à 61 nucléotides
|
|
|
|
|
(`MAX_PAT_LEN` vaut 64 dans `obiapat/apat.h`). État **actuel** de obiprimers : **31 bases au maximum**, limite
|
|
|
|
|
inscrite dans `match.go:48`, `words.go:44`, `pairs.go:31`, dans `obikmer` (`encodekmer.go`,
|
|
|
|
|
`seqquorum.go:63` : k-mers sur 64 bits, 2 bits par base) et par des tampons fixes `[32]byte`
|
|
|
|
|
(`pairs_eval.go:208`). `obithermo` n'a pas de limite de longueur (tranches).
|
|
|
|
|
|
|
|
|
|
La stratégie de l'index de graines **n'est pas bloquée** : elle se généralise à 61 bases (et 64) avec une fenêtre
|
|
|
|
|
de **128 bits** (deux mots de 64 bits, décalage et popcount sur les deux) ; les moitiés (<= 31 bases) tiennent
|
|
|
|
|
dans un mot et le chemin d'index haché pour les grandes graines est déjà utilisé et testé (k = 25 et 31).
|
|
|
|
|
L'oracle de test existant (`matchNaive`) fixe la justesse. Le compteur de mots stricts (k-mers sur 64 bits,
|
|
|
|
|
type partagé d'`obikmer`) resterait limité à 31 : **proposition** : chercher les mots conservés avec un k <= 31
|
|
|
|
|
(le « coeur » conservé), puis obtenir les amorces plus longues par **extension** pendant la phase de Tm
|
|
|
|
|
(22.3), vérifiée par l'appariement généralisé.
|
|
|
|
|
|
|
|
|
|
### 22.3 Optimisation de Tm : réponses aux questions de 21.3
|
|
|
|
|
|
|
|
|
|
(a) **Cible sur l'apparié non parfait** (la Tm de l'amorce sur les sites réels, avec leurs erreurs), pas sur
|
|
|
|
|
l'appariement parfait. *Question restante* : quelle statistique des Tm de sites ? Le minimum (`tm_min` d'ecoPrimers)
|
|
|
|
|
est dominé par des valeurs aberrantes : sur les tables de référence on lit des minimums de 12 à 45 °C pour des
|
|
|
|
|
amorces dont la Tm parfaite est de 52 à 62 °C ; une cible sur le minimum imposerait des longueurs absurdes.
|
|
|
|
|
Proposition : cible sur la **moyenne ou la médiane** des Tm de sites (éventuellement pondérées par taxon), le
|
|
|
|
|
minimum restant rapporté ; ou un quantile bas réglable. À choisir.
|
|
|
|
|
(b) bornes de longueur : traitées en 22.2 (jusqu'à 61 bases possible avec la généralisation).
|
|
|
|
|
(c) **Extension et raccourcissement du côté le mieux conservé** (et non seulement par le 5', contrairement à ma
|
|
|
|
|
proposition). Cela se calcule avec un profil de conservation par position (fraction des sites cibles qui
|
|
|
|
|
portent la même base, comme le PSSM du tutoriel) autour de chaque amorce, tiré des occurrences déjà
|
|
|
|
|
trouvées. Attention : la contrainte `-3` s'applique à l'extrémité 3' *de l'amorce*, quelle que soit sa
|
|
|
|
|
position sur la séquence ; étendre ou raccourcir du côté 3' déplace donc cette extrémité et modifie la
|
|
|
|
|
longueur d'amplicon.
|
|
|
|
|
(d) **Intégrée à la recherche, en phase de post-traitement** de la même exécution de obiprimers (pas d'outil
|
|
|
|
|
indépendant pour l'instant).
|
|
|
|
|
(e) Une paire dont la Tm n'est pas atteignable dans les bornes est **écartée**.
|
|
|
|
|
|
|
|
|
|
### 22.4 En attente
|
|
|
|
|
|
|
|
|
|
Réponses de l'utilisateur sur la voie B (questions de 21.4) ; choix de la statistique de Tm (22.3-a) ; nom et
|
|
|
|
|
sort de l'ancien Bs (22.1) ; en-têtes éventuels à prévoir pour les colonnes de population d'évaluation.
|
|
|
|
|
|
|
|
|
|
## 23. Décisions : un seul Bs, tout en mémoire (2026-11-03)
|
|
|
|
|
|
|
|
|
|
**Statut : spécification, aucun code.** Cette section **remplace** la proposition de 22.1 (colonne `bs_examples`,
|
|
|
|
|
passage d'évaluation en flux).
|
|
|
|
|
|
|
|
|
|
### 23.1 Décisions de l'utilisateur
|
|
|
|
|
|
|
|
|
|
1. **Un seul indice Bs, calculé d'une seule façon.** Pas de colonne `bs_examples`, pas de variante : « on décide
|
|
|
|
|
un indice, il se calcule d'une certaine façon, point barre ». Le Bs d'ecoPrimers disparaît.
|
|
|
|
|
2. **Tout charger en mémoire.** Ne pas tout charger interdirait de lire la base de référence sur l'entrée
|
|
|
|
|
standard, que les obitools permettent ; la base est lue par le mécanisme de lecture standard
|
|
|
|
|
(comme `obiconvert`), sans format dédié. Le passage d'évaluation en flux de 22.1 est abandonné.
|
|
|
|
|
3. **Définition de Bs** : le nombre de taxons **bien identifiés parmi les cibles**, en considérant **tous les
|
|
|
|
|
barcodes amplifiés, y compris ceux hors des cibles et ceux des contre-exemples**. Une espèce cible est
|
|
|
|
|
mal identifiée si son barcode, unique parmi les cibles, est partagé avec une espèce non cible ou un
|
|
|
|
|
contre-exemple.
|
|
|
|
|
|
|
|
|
|
### 23.2 Définition formelle retenue (traduction de 23.1-3)
|
|
|
|
|
|
|
|
|
|
Pour une paire, soit A l'ensemble des séquences qu'elle amplifie, **de n'importe quel rôle** (cibles,
|
|
|
|
|
contre-exemples, autres). Pour un amplicon a, T(a) est l'ensemble des taxons (au rang choisi) des séquences de A
|
|
|
|
|
qui le portent. Un taxon cible t est **bien identifié** s'il existe un amplicon a produit par t avec T(a) = {t}.
|
|
|
|
|
|
|
|
|
|
### 23.3 Conséquences
|
|
|
|
|
|
|
|
|
|
- **Fin de la notion de séquence « ignorée »** : les séquences qui ne sont ni cibles ni contre-exemples ne sont
|
|
|
|
|
plus écartées à la lecture (comportement actuel, hérité d'ecoPrimers) ; elles sont **non cibles** : elles ne
|
|
|
|
|
comptent ni dans les quorums de sensibilité et de faux positifs, mais leurs amplicons comptent dans Bs.
|
|
|
|
|
Pour exclure des séquences de l'analyse, on filtre l'entrée en amont (`obigrep`), à la manière des obitools.
|
|
|
|
|
Le rôle « contexte » de 21.2 devient donc simplement « non cible ».
|
|
|
|
|
- **Les valeurs changent, y compris pour le tutoriel** : une paire conservée chez tous les vertébrés amplifie
|
|
|
|
|
aussi des non-Cyprinidae ; son Bs baissera par rapport aux tables d'ecoPrimers, même sans `-i`. Les tests de
|
|
|
|
|
non-régression de la section 17 et de la section 18 ne peuvent plus comparer Bs/identifiés avec ecoPrimers sur
|
|
|
|
|
la base entière. **Proposition, sans option ni colonne supplémentaire** : au niveau de la bibliothèque, un corpus
|
|
|
|
|
construit avec les seules cibles et contre-exemples (c'est ce que fait `LoadCorpus` aujourd'hui) redonne
|
|
|
|
|
exactement la définition d'ecoPrimers, car il n'y a alors aucune séquence hors sélection à amplifier ; les tests de
|
|
|
|
|
non-régression continuent d'utiliser ce corpus, la CLI charge toujours tout.
|
|
|
|
|
- **Coût mémoire** : tout le fichier est conservé (131 Mb de bases pour 194 Mo de tas dans le tutoriel, contre
|
|
|
|
|
5 Mb pour Cyprinidae aujourd'hui). Une représentation compacte (2 bits par base) reste possible plus tard ;
|
|
|
|
|
non décidée.
|
|
|
|
|
- **Coût de calcul** : l'appariement approché des mots et l'énumération des amplicons passent de la sélection à
|
|
|
|
|
tout le corpus (l'exécution `-r 7953 -i 1` du tutoriel, qui charge déjà tout, prend 1,9 s) ; les quorums ne
|
|
|
|
|
comptent toujours que cibles et contre-exemples.
|
|
|
|
|
|
|
|
|
|
### 23.4 Points à confirmer (propositions, non validées)
|
|
|
|
|
|
|
|
|
|
1. **Dénominateur de Bs** : taxons cibles **amplifiés** (comme le code d'ecoPrimers : 2 650 identifiés sur 3 805
|
|
|
|
|
amplifiés = 0,696) ou **tous** les taxons cibles ? Avec le premier, Bc (couverture) et Bs (discrimination)
|
|
|
|
|
restent indépendants et `Bc x Bs` est la part des cibles résolues par la paire, ce qui est le gain mesuré par
|
|
|
|
|
la sélection multi-marqueurs. Avec le second, Bs <= Bc et ce produit disparaît. **Je recommande le
|
|
|
|
|
premier.** L'article (« nombre de taxons identifiés sur |E| ») et le code divergent déjà.
|
|
|
|
|
2. **Taxon à plusieurs amplicons** : bien identifié dès qu'**un** de ses amplicons est unique (règle d'ecoPrimers),
|
|
|
|
|
ou seulement si **tous** le sont ? Je propose de garder la règle d'ecoPrimers.
|
|
|
|
|
3. **Séquence non cible sans taxon au rang choisi** : la traiter comme un taxon anonyme distinct (prudent :
|
|
|
|
|
elle empêche l'identification d'une cible qui partage son amplicon) ou l'ignorer ? Je propose le premier.
|
|
|
|
|
|
|
|
|
|
## 24. Règle d'identification de Bs, et l'indice BD (2026-11-03)
|
|
|
|
|
|
|
|
|
|
**Statut : spécification, aucun code.** Complète et corrige la section 23.
|
|
|
|
|
|
|
|
|
|
### 24.1 Décisions de l'utilisateur
|
|
|
|
|
|
|
|
|
|
1. **Dénominateur de Bs : les taxons cibles amplifiés** (comme ecoPrimers : 2 650 / 3 805 = 0,696).
|
|
|
|
|
Bc (couverture) et Bs (discrimination) restent indépendants ; `Bc x Bs` est la part des cibles résolues.
|
|
|
|
|
2. **Règle d'identification : une espèce est bien identifiée si TOUS ses barcodes ne sont associés qu'à
|
|
|
|
|
elle.** Dès qu'un barcode est partagé entre deux espèces, **les deux** sont mal identifiées. Cette règle
|
|
|
|
|
remplace celle de 23.4-2 (que j'avais proposé de garder).
|
|
|
|
|
3. **Nouvel indice BD (barcode discrimination)** proposé par l'utilisateur : la part des **barcodes** qui
|
|
|
|
|
mènent sans ambiguïté à une espèce cible. Exemple de l'utilisateur : A porte les barcodes A1 et A2, B porte
|
|
|
|
|
A2 et B1. Ni A ni B ne sont bien identifiées (elles partagent A2), mais **A1 et B1 sont discriminants**, A2
|
|
|
|
|
ne l'est pas. Ici Bs = 0/2 et BD = 2/3. (Avec la règle d'ecoPrimers on aurait Bs = 2/2.)
|
|
|
|
|
|
|
|
|
|
### 24.2 ecoPrimers applique bien l'autre règle (vérifié)
|
|
|
|
|
|
|
|
|
|
Lecture de `taxstats.c` : pour chaque amplicon distinct (parmi les exemples), on dresse l'ensemble de ses
|
|
|
|
|
taxons ; si cet ensemble n'a qu'**un** taxon (`taxoncount == 1`), ce taxon est marqué bien identifié. Un
|
|
|
|
|
taxon est donc compté **dès qu'un** de ses amplicons lui est propre. Confirmations : (i) mon implémentation de
|
|
|
|
|
cette règle reproduit toutes les colonnes `identifiés` et Bs de plus de vingt tables d'ecoPrimers (sections
|
|
|
|
|
12, 15, 17, 18) ; (ii) recalcul indépendant avec `obipcr` + Python sur la paire n° 1 de `Cyprinidae.ecoprimers`
|
|
|
|
|
(320 amplicons chez `obipcr`, 318 chez ecoPrimers qui impose `-3 2`) : règle « au moins un barcode unique »
|
|
|
|
|
239/312 = 0,766 contre 237/310 = 0,765 pour ecoPrimers ; règle « tous uniques » 238/312 = 0,763 ; **BD =
|
|
|
|
|
240/265 = 0,906** (265 barcodes distincts). **Portée de (ii)** : sur cette paire les deux règles ne diffèrent
|
|
|
|
|
que d'**une** espèce sur 312, car les données du tutoriel ont un génome par espèce (4 espèces seulement
|
|
|
|
|
portent plusieurs barcodes) : ce recalcul ne tranche pas entre les règles à lui seul ; la preuve est le code
|
|
|
|
|
et les tables reproduites.
|
|
|
|
|
|
|
|
|
|
### 24.3 Conséquences
|
|
|
|
|
|
|
|
|
|
- **Les différences entre règles seront faibles sur le tutoriel** (un génome par espèce) et **plus fortes**
|
|
|
|
|
sur des bases à plusieurs séquences par espèce (variation intra-spécifique), typiquement des bases de loci courts.
|
|
|
|
|
- **Non-régression** : la règle changeant, l'égalité des colonnes `identifiés` et Bs avec ecoPrimers n'est plus
|
|
|
|
|
atteignable, même avec un corpus restreint aux cibles et contre-exemples (annule la proposition de 23.3 sur ce
|
|
|
|
|
point). Toutes les autres colonnes (séquences, taxons, Bc, Yule, longueurs, GC, Tm, drapeaux good) restent
|
|
|
|
|
comparables. Pour Bs, BD et `identifiés` : tests sur cas synthétiques (dont l'exemple A1/A2/B1 ci-dessus) et
|
|
|
|
|
**vérification indépendante** par `obipcr` + script, comme en 24.2, sur des paires choisies.
|
|
|
|
|
- **Seuil `-T` (spécificité minimale, 0,6 par défaut)** : calibré sur l'ancienne règle, plus indulgente. Le
|
|
|
|
|
défaut sera peut-être à revoir ; à décider avec la spécification complète.
|
|
|
|
|
- **Implémentation (plus tard)** : la phase 2 de `FindPairs` doit enregistrer le hash d'amplicon de **toutes** les
|
|
|
|
|
séquences amplifiées (cibles, contre-exemples, non-cibles) et non plus des seuls exemples ; un taxon cible est
|
|
|
|
|
mal identifié si l'un de ses amplicons est porté par un autre taxon.
|
|
|
|
|
|
|
|
|
|
### 24.4 Questions restantes
|
|
|
|
|
|
|
|
|
|
1. **BD** : l'inclure dans la sortie, et dans le classement ? Dénominateur proposé : les barcodes distincts
|
|
|
|
|
portés par **au moins une cible** (un barcode propre à une non-cible ne « mène » pas à une espèce cible) ;
|
|
|
|
|
comptage par barcode distinct, sans pondération par le nombre de séquences.
|
|
|
|
|
2. **Non-cible sans taxon au rang choisi** (23.4-3, proposé, non confirmé) : taxon anonyme distinct, donc
|
|
|
|
|
barcode partagé = ambigu (prudent).
|
|
|
|
|
3. **`-T` par défaut** (voir ci-dessus).
|