Une difficulté s’ajoute pour le dernier restaurant car les ‘é’ de Célébrités sont convertis en HTML (& eacute;)…

Le fichier source original est ici.

Principe
Le principe est donc de rechercher pour chaque ligne, le restaurant qui a la similarité la plus forte soit 49 952 mesures (224 x 223) après conversion des chaînes en majuscule.
Pour chaque restaurant, je considère que le bon doublon a été correctement trouvé s’il arrive avec le plus fort indice par rapport aux 222 autres restaurants.
J’ai comparé les 3 algorithmes Jaro-Winkler (JW), Damerau-Levenshtein (DL) et les 6 indices Cosinus/Dice/Jaccard/… (IS), en recherchant pour chacun la meilleure configuration.

Résultats
Concernant DL, pas de problème pour trouver la meilleure configuration car il suffit de passer les 2 chaînes en argument de la fonction.
Damerau-Levenshtein a permis de détecter 185 doublons sur 224 soit 82,6% de réussite.

Concernant Jaro-Winkler, on peut jouer sur la longueur du préfixe entre 0 et 4. Les résultats obtenus sont :

Dans cet exemple, la meilleure longueur de préfixe est 2 avec 214 doublons détectés soit un taux de réussite de 95,5%, la distance de Jaro seule (0) donne le moins bon résultat.

Enfin pour l’algorithme IS, le choix du paramétrage est plus complexe car on peut choisir entre 6 indices de similarités, la longueur des Grammes (0 = mot à 5), l’inversion ou non des grammes et une distance maximum de recherche des grammes communs.
Pour la distance maxi, j’ai laissé à -1 (pas de limite de distance) car elle fournit les meilleurs résultats dans cet exemple et la recherche de grammes inversés donne ici de moins bons résultats.

J’ai donc joué sur le reste des paramètres (type d’indice et longueur des grammes) et les résultats sont synthétisés ici :

Les unigrammes (1) ont les moins bon résultats, la variabilité des résultats entre les indices diminue avec la longueur des grammes, les trigrammes et Simpson ont en moyenne les meilleurs résultats.

Pourcentage de réussite des indices en fonction de la longueur des grammes :

Finalement, l’indice de Simpson avec des bigrammes donne ici le meilleur résultat : 219 doublons détectés soit 97,8% de réussite !

Le tableau suivant indique le nombre de doublons détectés par position des résultats hormis le Top 1. Par exemple, 18 nouvelles bonnes détections faites par DL dans les Top 2 des résultats et Simpson en détecte 4 soit 223 détections cumulées (Top 1 et Top 2) sur 224 !.

Après avoir vu rapidement la capacité des indices à détecter les vrais doublons, il faut vérifier leur capacité à être discriminant entre les restaurants et compter les éventuels ex aequo.
Imaginez un algo qui retourne un indice identique pour tous les restos : Ses résultats seraient parfaits mais pour chaque restaurant on aurait 223 restaurants détectés dans le Top 1 !

Via une requête, j’ai donc calculé la position absolue du vrai doublon pour chaque algorithme et chaque ligne. Des ex aequo sont présents si la position absolue est supérieure au classement.

JW n’est affecté qu’une fois par un ex aequo et ceci pour un classement du vrai doublon en 28ème position.
IS en a obtenu un seul sur un Top 1 et DL a eu 13 fois un ou plusieurs ex aequo.

Conclusion
Dans cet exemple, l’indice de Simpson a détecté le plus de doublons dans le Top 1 (219 sur 224) et 223 dans le Top 2 des résultats.
Si vous le souhaitez, vous pouvez ajouter vos propres résultats de vos algorithmes en commentaire du billet.

@+

Philippe

 
Paramètres de la fonction
‘S1′ et ‘S2′ correspondent aux deux chaînes de caractères à étudier.
‘LongueurPrefixe’ permet de choisir la longueur du préfixe commun entre les deux chaînes. Cette longueur permet de calculer l’apport de Winkler à l’algorithme de Jaro. Cette longueur est comprise entre 0 et 4 (3 par défaut). La distance de Jaro est retournée lorsque ce paramètre est égal à 0.
‘TypeComparaison’ permet de choisir le type de comparaison entre les deux chaînes : Soit une comparaison binaire (par défaut) soit une comparaison textuelle (moins restrictive car ne tient pas compte de la casse des caractères mais généralement moins performante).
Il sera souvent nécessaire de prétraiter les chaînes par UCase()/LCase() (casse uniforme des caractères), Trim() (suppression des espaces en début et fin de chaîne) et remplacer les caractères diacritiques pour ne pas ‘parasiter’ l’algorithme (voir ici).

Tests
J’ai récolté dans une publication de W. E. Winkler (voir référence plus bas) et sur le Web des exemples pour tester les résultats de mon code. La longueur du préfixe est fixée à 4.

 
Résultats et commentaires

 
Les distances obtenues sont parfois différentes des distances attendues (4 écarts constatés).
Concernant les couples HARDIN/MARTINEZ, ITMAN/SMITH, JON/JAN, ils sont fournis par W. E. Winkler qui devait utiliser un algo un peu différent de celui décrit dans Wikipédia (en effet, sa fonction strcomp.c est plus complexe…)

Concernant le couple TRAVEL/TRAIN et la distance attendue de 0,9, je pense qu’il s’agit d’une coquille de l’auteur car la distance de Jaro dans la même publication était seulement de 0,7.

De plus, l’applet java de ce site donne des résultats proches ou identiques aux miens.

Remarque
L’éloignement maximal (variable dMax dans mon code) devrait être calculé à l’aide de la plus grande longueur de chaîne. J’ai préféré utiliser la plus courte pour éviter des résultats ‘étonnants’ avec certaines chaînes de caractères.
Par exemple, en allongeant la seconde chaîne ‘cba’ et en utilisant la plus grande longueur des deux chaînes de caractères, on obtient :

La similarité diminue avec 4 caractères (0,528) puis augmente paradoxalement avec 5 caractères (‘cbauu’ donne 0,756)!
Pourquoi ?
Dans le 1er exemple, l’éloignement maximal (variable dMax dans le code) est égal à 1 et on obtient une seule concordance (lettre ‘b’) entre les 2 chaînes.
Dans le 2ème exemple, la similarité chute légèrement car la longueur de la chaîne n°2 est de 4 au lieu de 3 et celle-ci intervient en tant que dénominateur dans le calcul de la distance de Jaro. L’éloignement maximal reste égal à 1.
Dans le 3ème exemple, l’éloignement maximal est égal à 2 car la longueur de la chaîne n°2 est de 5 caractères (arrondi supérieur de 5/2 – 1 = 2). Cet éloignement permet d’obtenir 3 correspondances (‘a’, ‘b’, ‘c’) et une transposition (‘a’ et ‘c’). Ces 3 correspondances au lieu d’une seule augmentent la similarité malgré la transposition et la longueur de la chaîne n°2.

Pour éviter ce problème, une solution consiste donc à utiliser la plus petite longueur des deux chaînes :

 
Conclusion
Algorithme rapide et efficace sur des chaînes relativement courtes.

Références
Wikipédia: Distance de Jaro-Winkler
Publication de W. E. Winkler.

@+

Philippe

 
Remarques
Si vous souhaitez extrapoler la formule à d’autres SQL, il faut savoir que sous Access :

• True = -1 donc (Annee MOD 19 IN (5,16)) retourne -1 si vrai;
• L’opérateur ‘\’ de Annee \ 4 retourne seulement la partie entière de la division;
• Attention aussi à la priorité des opérateurs…

Il n’est pas possible non plus de copier directement la formule dans une fonction VBA car elle utilise des opérateurs spécifiques SQL (Between et In).
 
Exemples
Au lancement de la requête, un popup demande de saisir l’année souhaitée.

Si l’année est en dehors de la plage 1900 – 2099, NULL est renvoyé pour chaque colonne.

A noter
La formule pour le calcul des jours ouvrables de la FAQ Access n’est valable que pour la période comprise entre 1982 et 2048.

@+

Philippe

 
La fonction Ngram appelée par la fonction principale pour créer les grammes de la chaîne :

 
La fonction principale :

 
Définition
Un gramme (ou gram en anglais) est une sous-séquences continues de caractères de la chaîne.
 
Explications
Cette fonction ne mesure pas une distance entre les deux chaînes, elle compte seulement les grammes communs entre les deux chaînes S1 et S2. Ce compte est ensuite divisé par un coefficient qui distingue les indices entre eux : Ce dénominateur peut être la moyenne géométrique du nombre de n-grams (n1 et n2), la moyenne arithmétique, le nombre maxi, mini…
Le choix des indices est :

• Cosinus (équivalence : coefficients de Ochiai et de Otsuka)
• Dice (équivalence : Pirlot’s index, Sorensen, Tversky (alpha=beta=0.5), ~Czekanowski)
• Jaccard (équivalence : Tversky (alpha=beta=1), ~Tanimoto)
• Kulczynski (son second coefficient)
• Braun-Blanquet (dénominateur : max(n1,n2))
• Simpson (dénominateur : min(n1,n2))

Si le nombre de n-grams est identique entre les deux chaînes, les indices retournent la même valeur mis à part l’index de Jaccard. Par défaut le coefficient de Dice est utilisé.

La longueur des sous-séquences (paramètre TypeNgram) peut varier entre 0 et 5. Zéro indique qu’un n-gramme correspond à un mot, 1-gramme ou unigramme correspond à chaque caractère de la chaîne, 2-gramme ou bigramme est composé de deux caractères, jusqu’à 5-grammes. Au-dessus de 5-grammes la Prévention Informatique ne conseille pas de prendre le clavier !
Par exemple, les bigrammes de ‘abc’ seront ‘%a’, ‘ab’, ‘bc’ et ‘c#’ avec % et # des caractères non utilisés.

Le paramètre suivant (InversionGram) autorise ou non de compter un gramme inversé. Par exemple, ‘ab’ et ‘ba’ seront communs si InversionGram = True.

Le paramètre MaxDistance définit ou non une distance maximale (en valeur absolue) entre deux grammes communs. Si deux grammes communs sont trop éloignés, ils ne seront pas comptabilisés. Par exemple, la similarité calculée est égale à 0 si les chaînes sont ‘ab’ et ‘ba’ avec n-gram=1 et une distance maxi de zéro. Aucune limite de distance n’est définie si MaxDistance = -1.

Enfin, le dernier paramètre définit le type de comparaison entre les deux chaînes (binaire ou textuelle).

Ces indices et celui de Damerau-Levenshtein n’ont pas une réelle corrélation car ils ne mesurent pas la même chose.

Exemples
Des anagrammes qui retournent un indice de similarité parfait (1) :

Dans le deuxième exemple, on utilise l’indice de Simpson car il divise le nombre de grammes communs par le plus petit nombre de n-grams entre n1 et n2 ce qui permet d’obtenir un indice égal à 1.
 
Via une requête SQL, une recherche d’anagrammes sur des mots de 12 lettres dans une table a donné (après suppression des accents) :

 
Si on reprend l’exemple de ‘pascal obispo’ mais avec des bigrammes, l’indice tombe à 0,36 et remonte à 0,43 si on autorise les inversions car ‘… o…’ est commun à ‘…o …’ de ‘Pablo Picasso’. L’indice chute à 0,2 avec des trigrammes.

On peut aussi jouer sur la distance maxi pour modifier sensiblement le résultat :

 
Performance
Cette fonction semble être 5 à 6 fois plus rapide que la fonction de Damerau-Levenshtein. Le principe mis en jeu est différent et les différentes possibilités de réglages permettent d’adapter l’algorithme à de nombreux cas de figures.

Voir aussi le billet sur la distance de Jaro-Winkler.

@+

Philippe

Code de la fonction VBA

 
Exemples d’utilisation
Un collectionneur de modèles réduits, a noté consciencieusement ses achats de lots de voitures sur une feuille quadrillée. Un ami, utilisateur débutant d’Access, a porté ce document dans une table Access sans connaître les formes normales de Codd !

Voici le code pour créér et peupler partiellement la table dont la structure n’est pas à suivre…

Cette table contient 6 colonnes (Marque, Modèle, DateAchat, Couleur des voitures, Nombre de voiture du lot, Prix du lot).
Chaque ligne de la table correspond à l’achat d’un lot de voitures et toutes les voitures d’un lot ont la même couleur.

Le collectionneur souhaite obtenir des infos sur sa collection en concaténant l’information dans une colonne car c’est plus simple à lire…

Quels sont les modèles achetés de la marque Peugeot ?
Comme la colonne pivot ‘Marque’ doit être égale à ‘Peugeot’, on peut écrire la simple requête suivante :

La valeur pivot est ‘Peugeot’, la colonne pivot (ou de regroupement) est ‘Marque’, la colonne à concaténer est ‘Modele’, la table est ‘tConcat’, la clause Where est vide «  », pas de regroupement des lots ayant le même modèle d’où la valeur 0, on retourne les modèles dont le nom est vide ou NULL (False), on souhaite trier par ordre Ascendant les modèles concaténés (True), et le séparateur entre les modèles est une virgule ‘,’.

On obtient donc :

Le collectionneur est satisfait mais il préfère regrouper les modèles communs et ajouter un espace après la ‘,’
La requête devient :

Pour regrouper les modèles, il suffit de passer à 1 au lieu de 0 le paramètre ‘RegrouperCompter’. De plus, le séparateur devient ‘, ‘ au lieu de ‘,’.

On obtient alors :

Il est satisfait mais il perd une information importante qui est le nombre de lots achetés et finalement il se demande si le séparateur ‘ / ‘ ne serait pas mieux…
La solution devient :

Pour afficher le compte par modèle, on passe la valeur du paramètre ‘RegrouperCompter’ à 2, et le séparateur est modifié.

Résultat :

 
Qu’elles sont les dates d’achat de ces lots du plus récent au plus ancien ?

La colonne à concaténer devient ‘DateAchat’ et le paramètre ‘TriAscendant’ devient ‘False’.

Résultat :

 
Quels sont les prix d’achat de ces lots ?

On obtient :

On remarque que le dernier compte (1) est sans valeur. En effet, un prix n’était pas renseigné dans le document…
Le collectionneur me dit alors : ‘Cachez-moi cette erreur que je ne saurais voir…’

La requête devient donc :

Il suffit de mettre à ‘True’ le paramètre ‘PasVideNULL’.

On obtient finalement :

 
Quels sont les prix d’achat, toutes marques confondues ?
Il est normalement nécessaire de renseigner la valeur et la colonne du pivot…
La solution consiste à mettre 0 pour ‘ValeurColonnePivot’ et ‘0’ pour ‘NomColonnePivot’
La requête devient :

et le résultat :

Ca serait possible d’avoir tous les prix unitaires ?
Requête :

On déclare que la colonne concaténée est la division du prix sur le nombre de voiture du lot.
Résultat :

 
Quels sont les modèles de chaque marque ?
Cette fois-ci, il faut utiliser la clause FROM de la requête pour passer en revue l’ensemble des marques :

Résultat :

 
Quels sont les marques et modèles pour chaque couleur ?

Résultat :

Puis-je avoir une présentation inversée ?

qui donne :

Enfin, je souhaite afficher séparément les colonnes ‘Marque’ et ‘Modèle’ et ne pas voir les informations pour ‘Citroën’
La requête :

On remarquera l’utilisation du paramètre ‘Filtre’ de la fonction ConcatColonne pour écarter la marque ‘Citroën’ de la concaténation. Dans ce cas précis, l’utilisation du filtre n’est pas indispensable puisque la requête écarte elle-même cette marque (voir clause HAVING).
Résultat attendu :

 
Performance
La fonction (et la requête sous-jacente!) est exécutée pour chaque ligne de la table ce qui ralentit sensiblement la requête principale.
Il faudra donc limiter son usage à une table ou requête peu peuplée (< 10 000 lignes ?) et si possible, indexer avec doublons la colonne pivot.
De plus, pour ne pas dégrader les performances, éviter de réaliser des opérations complémentaires sur la colonne concaténée (Where, Order by, Group by) dans la requête principale.

Lien
Voir ce billet pour réaliser une transposition inverse.

@+

Philippe

 
Explications
L’algorithme de Levenshtein mesure la distance entre deux chaînes de caractères qui est basée sur le nombre minimal de suppressions/insertions/substitutions de caractères pour passer d’une chaîne à l’autre.
L’algorithme de Damerau-Levenshtein ajoute en plus la transposition bien connue des dyslexiques du clavier (‘rehcerhce’ au lieu de ‘recherche’)…

Mon implémentation ne retourne pas une distance mais un indice de similarité allant de 0 à 1. La valeur 1 indique une similarité maximale entre deux chaînes. De plus, elle réalise une comparaison binaire des caractères, d’où parfois la nécessité de prétraiter les chaînes (UCase(), Trim(), sans accent,…)

La complexité de l’algorithme est O(m*n) avec m et n la longueur des chaînes ce qui limite son usage à des chaînes relativement courtes, des mots.
 
Exemples
On peut utiliser cette fonction dans une requête SQL pour rechercher des doublons sur une petite(!) base de données en se basant sur une ou des colonnes (nom/prénom/adresse/…) ou afficher les données les plus similaires à une chaîne de recherche.

Par exemple, mon doigt a rippé par deux fois sur mon clavier AZERTY et j’ai enchaîné un redressement un peu tardif qui a eu pour résultat : ‘tbalrette’

La recherche de similarité dans une table de synonymes (+ de 36 000 entrées) a affiché :

• barette (0,78)
• tablette (0,78)
• turlurette (0,70)
• targette (0,67)
• …

Je voulais écrire ‘tablette’.

Comme d’habitude, vous pouvez tester la fonction dans la fenêtre Exécution du VBE :

 
(*)

• ICC : Interface Chaise-Clavier
• ITCC : Interface Téléphone-Chaise-Clavier
• IPCC : Interface Papier-Chaise-Clavier
• ITPCC : Interface Téléphone-Papier-Chaise-Clavier
• ITPCCC : Interface Téléphone-Papier-Collègue-Chaise-Clavier

Pour en savoir plus sur le thème errare humanum est…

@+

Philippe

 
Paramètre
Elles acceptent un nombre quelconque de valeurs en paramètre grâce à l’utilisation du type ParamArray.

Particularités

• Ces fonctions gèrent les NULL c’est à dire qu’elles ne renvoient un NULL que si toutes les valeurs passées en paramètre sont nulles.
• Le type des paramètres doit être uniforme et peut être numérique, date ou string. Une adaptation du code sera nécessaire pour une bonne gestion des accents et autres caractères particuliers.

Exemples

@+

Philippe

Exemple d’utilisation
Recopier la ligne suivante dans la fenêtre ‘Exécution’ de l’éditeur Visual Basic (F11) puis appuyer sur ‘Entrée’ pour l’exécuter.

Explications
Le premier paramètre de la fonction contient la chaine à modifier.
Le deuxième paramètre est un peu particulier car il s’agit d’une suite de paramètres qui sera interprétée comme un tableau de variants. Ce tableau contient l’ensemble des substitutions à réaliser (couple chaine recherchée/chaine de remplacement) et éventuellement un booléen qui indique le type de comparaison (binaire ou textuelle) pour les remplacements suivants.

Par défaut, la fonction effectue une comparaison binaire pour rechercher et remplacer les sous-chaines c’est à dire qu’elle est sensible à la casse des caractères.

Dans notre exemple, on va tout d’abord substituer le caractère ‘_’ par un espace (‘_’,’ ‘) puis réduire le nombre d’espaces contigus en un (‘ ‘,’ ‘). A ce stade on obtient :

Lorsque la chaine de remplacement est plus courte que la chaine recherchée, la fonction réalise une boucle de réduction. Par exemple, 5 espaces contigus seront réduits en un même si la chaine recherchée n’est que de deux espaces.

L’étape suivante (‘ A ‘,’ à ‘) recherche la lettre A en majuscule entourée d’espaces, on remplace ensuite le i accentué par son équivalent sans accent (‘î’,’i’) puis le ‘é’ par ‘er’.

L’étape suivante (True ou tout chiffre différent de 0) indique à la fonction que l’on souhaite réaliser maintenant des comparaisons textuelles (vbTextCompare) donc insensibles à la casse des caractères. L’étape suivante (‘ma’,’La’) remplacera donc le texte ‘ma’ par ‘la’ quel que soit la casse des caractères.

On pourrait ajouter d’autres remplacements et revenir aussi à une comparaison binaire (False ou le chiffre 0).

Remarque
Dans le cas d’une réduction de chaine, on réalise une boucle qui ne s’arrête que si la longueur de la chaine est inchangée (…Loop Until a = b) après la fonction Replace(). Cette méthode est moins efficace que :

mais on risque d’entrer dans une boucle infinie si on souhaite réduire par exemple ‘oe’ en ‘Œ’ avec une comparaison textuelle… En effet, cette ligature est interprétée comme équivalente à ‘oe’ :

Access retourne la valeur 1 bien que l’on s’attend à obtenir 0…

Pour le fun !
Une autre solution pour réduire les espaces :

Ce type de méthode est parfois utilisé dans les requêtes SQL pour s’affranchir d’une fonction personnelle dans la requête :

@+

Philippe

La fonction est d’autant plus rapide si on ne conserve pas la casse de la chaine et si on réduit les caractères accentués recherchés au strict nécessaire.
Il est parfois utile de conserver la casse des caractères de la chaine dans une requête d’insertion ou de mise à jour ou si l’on souhaite faire une recherche sur la casse des caractères seulement.

Suivant les cas, il est performant de tester avant de rentrer dans les boucles si la longueur de la chaine est supérieure à zéro et/ou dans le cas où l’on souhaite conserver la casse, de faire un screening avant les deux recherches InStr().

Exemple d’utilisation
Dans la fenêtre Exécution du VBE :

@+

Philippe

Résultat attendu du jeu de test
Nous remarquons que la période :

• de la 1ère ligne [03/01/2012-03/01/2012] est chevauchée par celle de la 2ème [20/12/2011-04/01/2012]
• de la 3ème ligne [04/01/2012-07/01/2012] chevauche celle de la 2ème [20/12/2011-04/01/2012]
• de la 4ème ligne [06/01/2012-10/01/2012] chevauche celle de la 3ème [04/01/2012-07/01/2012]

Après regroupement, l’étendue de cette première période va du 20/12/2011 au 10/01/2012

La ligne n°5 (01/05/2012-01/05/2012) n’est chevauchée par aucune autre période et les 4 dernières lignes donnent une période du 02/05/2012 au 10/05/2012.

Le résultat attendu est :

• 20/12/2012 – 10/01/2012
• 01/05/2012 – 01/05/2012
• 02/05/2012 – 10/05/2012

La requête
Il existe plusieurs méthodes pour arriver au résultat mais voici la requête la plus performante sous MS Access (et cerise sur le gâteau, visible dans l’éditeur de requête !) :

Explications
La première sous-requête de la clause FROM (SELECT DateDebut…) retourne la date minimale des périodes chevauchées. En effet, la clause WHERE de cette sous-requête ne conserve que les dates de début qui sont inférieures ou égales aux périodes qui les chevauchent éventuellement.
Prenons par exemple la ligne n°1 (03/01/2012). Sa date de début est-elle <= à la date de début de la période qui la chevauche ? La réponse est non puisque la date de début de la période du 20/12/2011 au 04/01/2012 est inférieure. La date du 03/01/2012 est donc retirée et ainsi de suite pour chaque ligne de la table.
Le 'Group By DateDebut' permet, au cas où, de regrouper les lignes qui ont une même date de début.

La deuxième sous-requête de la clause FROM (SELECT DateFin …) applique le même principe mais pour la date de fin.

A ce niveau là, on a visiblement pas de lien entre la date de début et la date de fin des périodes regroupées… d’autant plus que l’on réalise une jointure croisée entre les dates pour que la requête soit visible dans l’éditeur.

Pour s’en sortir, on retire dans un premier temps les lignes incohérentes qui ont une date de fin < à la date de début (…WHERE t1.DateDebut <= t2.DateFin…)
Et la finesse finale qui consiste à dire que la date de fin de chaque regroupement de périodes est celle qui est la plus petite puisque nous avons retiré dans la clause WHERE précédente les périodes incohérentes et que les périodes restantes ne peuvent se chevaucher.
On ajoute un GROUP BY sur la date de début pour permettre l'utilisation de la fonction MIN() sur la date de fin.

Test de performance
Voici une petite fonction qui va générer 2000 lignes dans la table pour tester la performance de la requête

@+

Philippe