StrPos façon Boyer-Moore et tolérant à fautes de frappes Corrigé
cs_pseudo3
Messages postés
268
Date d'inscription
mardi 24 juillet 2007
Statut
Membre
Dernière intervention
2 février 2021
-
30 juil. 2015 à 09:24
piette Messages postés 68 Date d'inscription jeudi 11 décembre 2008 Statut Membre Dernière intervention 16 juin 2019 - 23 sept. 2015 à 18:50
piette Messages postés 68 Date d'inscription jeudi 11 décembre 2008 Statut Membre Dernière intervention 16 juin 2019 - 23 sept. 2015 à 18:50
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/101107-strpos-facon-boyer-moore-et-tolerant-a-fautes-de-frappes-corrige
https://codes-sources.commentcamarche.net/source/101107-strpos-facon-boyer-moore-et-tolerant-a-fautes-de-frappes-corrige
23 sept. 2015 à 18:50
Salutations
23 sept. 2015 à 10:17
Merci pour votre compliment.
Cordialement.
23 sept. 2015 à 10:16
Merci pour vos compliments.
Quand j'aurai terminé avec le pain que j'ai sur la planche, je testerai votre "Recherche de mots dans texte".
En attendant rien ne vous interdit de publier une version ASM de "StrPos façon Boyer-Moore et tolérant à fautes de frappes" cela ferait avancer schmillblick...
Cordialement.
21 sept. 2015 à 23:40
superbe présentation.
Bonne vélocité.
Bravo
Salutations
15 août 2015 à 21:03
9 août 2015 à 11:08
Une amélioration consisterait à "calibrer" au préalable la SubString ainsi que le Texte de recherche afin d'y remplacer par un Chr "Espace" = #32 unique toute séquence de Chr consécutifs d'Espaces, de Chr de Tabulation et de Chr de Ponctuation car même en l'absence de faute de frappe il suffit que la SubString recherchée soit présente dans le Texte mais contienne par exemple un double Espace alors que la SubString n'en contient qu'un et l'occurrence bien que présente ne serait pas détectée. (ni avec PosEx, ni avec Boyer-Moore)
Comme cette amélioration qualitative s'accompagnerait d'une perte de vitesse il faudrait peser "le pour et le contre" pour trancher entre "priorité à la qualité" ou "à la vitesse" mais il pourrait s'agir d'une option.
Cordialement, et à +.
8 août 2015 à 12:30
En fait l'idée du coulisseau-pochoir à tests de concordance sur N trous < Length(SubString) avait comme objectif premier des recherches de gain de speed quand j'ai pris conscience qu'au gain de vitesse s'ajoutait le bénéfice de la tolérance aux fautes de frappe susceptibles de polluer le Texte dans lequel on cherche la SubString.
Et avec N = 6 trous la probabilité de ratisser une occurrence parasite est quasi nulle et en tous cas nettement inférieure à la probabilité de toucher le jackpot au LOTO sous réserve qu'il s'agisse de recherches dans du texte rédigé dans une langue courante et non dans une chaîne d'A.D.N.
Cordialement, et à +.
7 août 2015 à 21:36
5 août 2015 à 12:57
Toute suggestion d'amélioration sera la bienvenue.
Cordialement, et à +.
30 juil. 2015 à 09:46
La présente version Corrigée constitue une mise à jour de la précédente suite à :
- Suppression d'un bug dans l'édition des valeurs des sauts de la SkipTable,
- Modifications pour ajuster l'interface simplement à la résolution d'un autre écran,
(utilisable avec des résolutions égales ou supérieures à environ 800x600)
- Ajout de PopupMenus s'ouvrant sur Click-Souris-Droite dans les 3 RichEdit pour les copiers-coller.
- Nouvelle capture d'écran plus explicite au sujet de la tolérance aux fautes de frappe.
Cordialement, et à +.