OK
AJAX error!

Les forumsGrammalecteProposition de changement dans GraphSpell

Proposition de changement dans GraphSpell

Bonjour,

J'avais remarqué quelques incohérences dans la fonction de Jaro utilisé, j'ai donc repris une autre implémentation que j'ai modifié afin de prendre en compte la similarité au lieu de l'équalité ;) De plus j'ai extrait dans un fichier a part les fonctions de distance ;)

Le résultat pour de se petit changement sont là : git.gravier.pro…

Note: C'est basé sur la version généré du JS afin de tester facilement, il y a une petite page web avec quelque fonction de test qui peut être utilisé avec un mini serveur web !
le 25 mars 2021 à 18:45
J'ai avancer un peu les tests ;)

Dans le git le commit suivant :
Pour un peu de clarté j'ai extrait le code des suggestions de ibdawg vers un nouveau fichier et fait les ajustement nécessaire.

Ce que je pense faire :
Inclure directement le filtre des suggestion dans le nouveau fichier. Je pense que nous pouvons gagner en rapidité vu que l'adresse du mot nous l'avons déjà et donc nous pourrions avoir les morph beaucoup plus rapidement. (actuellement les morph pour le filtre repart de zéros).

Quelques questions que je me posent :
* Est-ce que les règles de filtre ne devraient-elles pas être intégré au dictionnaire ? Je trouve de que c'est très spécifique a un dictionnaire et qu'il a des chances que se soit pas nécessaire d'avoirs les même pour les dico perso.
* Même question pour le split du mot pour rechercher les suggestions !

Autres questions que je me posent mais qui demande plus de travail :
* Est ce que les composant de grammalect pour la conjugaison et la similarité ne devraient pas être intégrés a graphspell et donc au dictionnaire : c'est très fortement lié :s ?
* Est ce que le _dSugg dans le lecicograph ne dois pas être inclus au dico (même justification que précédemment) ?

J'ai d'autre idées mais il faut que je fasse plus exploration avant.
le 26 mars 2021 à 12:18
Je note ici en mémo.
Exemple d'idées à explorer, splitter l'arbre des dictionnaire en 3 :
- 1 avec les mots uniquement en minuscule (globalement les mots communs)
- 1 avec les mots mixte (globalement les mots propre / formule de chimie)
- 1 avec les mots en majuscule (globalement les sigles)
Je pense que pour la suggestion ça peut permettre un bon gain vu qu'il y aura moins de transformation a faire et tester dans deux des arbres mais ca complique pour les autres fonction (morph / stem / ...) et dans la génération du dictionnaire.

Globalement ca donnerait quelque chose de se type:
Si le recherche d'un mot est écrit en minuscule :
On recherche dans l'arbre 1 => si pas assez de réponse puis on met l'entrée en majuscule pour chercher dans l'arbre 3 => si pas assez de réponse on recherche dans l'arbre 2 avec tout un tas de transformation ;)

Si le recherche d'un mot est écrit en majuscule :
On recherche dans l'arbre 3 => si pas assez de réponse puis on met l'entrée en minuscule pour chercher dans l'arbre 1 => si pas assez de réponse on recherche dans l'arbre 2 avec tout un tas de transformation ;)

Si le recherche d'un mot est écrit en "mixte":
On recherche dans l'arbre 2 => si pas assez de réponse puis on met l'entrée en minuscule pour chercher dans l'arbre 1 => si pas assez de réponse on met l'entrée en majuscule recherche dans l'arbre 3 ;)

A médité ;)
le 26 mars 2021 à 13:03
Bonjour,

J'ai commencé a faire des expérimentations donc sur git.gravier.pro… aux commit de619d6626 j'ai implémenté une spécialisation dans ibdwag qui ne fait les différents remplacement unique si les caractères et les bi-gramme existe dans le dictionnaire => ça fait gagner un peu en performance ;)

---

Sinon j'ai commencé en local mon idée de la séparation du dictionnaire.
Pour la séparation j'ai utilisé :

^([a-zà-öø-ÿœ ’-]+)\t.*\t.*$ => dic_min ("nEntry":501603)
^([A-ZÀ-ÖØ-ߌ ’-]+)\t.*\t.*$ => dic_maj ("nEntry":612)
si aucune des deux => dic_other ("nEntry":11035)


Ceci permet de généré 3 dico normal ;)

Ensuite je les assemble avec un petit script qui génère un fichier du formt:

{
"sHeader":"/grammalecte-multi/",
"maj": data_dic_maj,
"min": data_dic_min,
"other": data_dic_other
}



Malgré que l'unification ne soit pas optimisé (vu qu'il contient 3 dico) le fichier multi est de taille en octet inférieur.

Bon les choses se compliquent, il faut faire pas mal de changement de code. Un des plus grand changement c'est qu'il faut partagé les liste des suggestions, la gestion du multi_dic.
Pour les lookup / morph / stem / ... pour le moment j'ai juste fait le minimum de changement.

Au niveau performance si à chaque fois on cherche dans tous les dico on perds :s
MAIS si on analyse le mot soumis a la suggestion et qu'on utilise le même genre de regex pour le classifier :
On peut je pense considéré que s'il est de catégorie "other" ne faire la recherche que dans le sou-dico "other" se qui fait que l'entrée est "Co2" on passe de 120ms à 43ms
Si l'entré est de catégories "maj" ou "min" on recherche dans les deux sous dico "maj" et "min" en commençant par celui de la même case que l'entré on passe par exemple pour "coeur" de 64ms à 56ms / pour "exsepttion" de 27ms à 21ms

Pour le moment ma conclusion:
Le multi dico est une semi-bonne idée. Je pense que ça peut apporter un bon gain mais surement si la séparation est faite autrement du genre qu'en deux parties une qu'avec des lettres et une autre avec les chaines avec des symbols/nombre.
Sinon peut être juste garder la liste partagé mais uniquement l'appliquer pour les dicos perso et communautaire... Ce qui fera par contre qu'il n'y aura plus qu'une liste de suggestion.

Si vous avez des idées, remarque n'hésitez pas à les faire !!!

PS: les temps sont pour 10 fois la recherche.
le 29 mars 2021 à 13:23
Je suis très pris en ce moment. Je regarderai ça ultérieurement.
le 29 mars 2021 à 21:16
Pas de soucis !
De toute façon, je pense avoir fait des erreurs dans le multi_dic vu que j'ai poussé un peu les testes et certains résultats des tests sont blizzard :s
Je préviendrait quand j'aurais quelques chose de stable et exploitable.
le 30 mars 2021 à 23:26

Notification par e-mail    0