Projet de dictionnaires arabes

Adel Medine a écrit:En vérité cela dépend aussi de la source de données. S'il s'agit de dé-vocaliser un dictionnaire il est clair que la stratégie sera différente. Un code totalement encore différent. On utiliserait le parallélisme en plus au moins. Après selon l'usage(web par exemple) on affichera que très rarement tout un dico dé-vocalisé sur une même page. La stratégie sera différente.

Tu l'entends cela ?

Oui on est d'accord sur ça je ne dis pas le contraire au contraire j'ai bien conscience que la taille de la string est un paramètre important à prendre en compte que ce soit du point de vue mémoire ou rapidité (oui car dé-vocaliser un long texte comme le noble Qur'ân prend un certain temps même si c'est vrai qu'aujourd'hui les pc sont rapides...).

Tu sais il y a un logiciel dont j'avais déjà parlé et qui peut lire de gros textes de plusieurs volumes (des tafsîr par exemple) eh bien ce logiciel a une fonction de recherche très rapide et c'est franchement agréable.

La rapidité et la mémoire c'est je pense aussi pour ça que certains utilises une translittération des caractères arabes de sorte qu'à un caractère il corresponde juste un seul octet ! L’Unicode c'est deux octets minimum et l'UTF8 c'est entre les deux.

Wa Allâhu a'lam.

J'ai testé des traducteurs comme module dans mon navigateur web pour arabe et anglais. On peut traduire des pages entières rapidement.

Oui tu as raison la rapidité et la mémoire sont des points importants. Pour la mémoire c'est plus facile d'en rajouter, les serveurs aujourd'hui en ont de plus en plus. pour la rapidité c'est la partie qui ne peut pas être résolue avec du matériel. Ce qui est important aussi c'est la taille et lisibilité du code.

Pour le Coran par exemple il faut regarder du côté de la parallélisation. Ce qu'on nomme les Threads et les Task(qui est légèrement différent comme concept par rapport au thread léger)

Adel Medine a écrit:Je n'ai pas vu de code avec charAt mais une fois de plus il faut poser les contextes d'utilisations et faire des mesures pour les grosses volumétriques et traitements à risques.

Oui je n'ai pas dit que je l'avais fait j'ai juste posé le problème et son éventuelle solution mais je le ferais inchâ-a Allâh.

Adel Medine a écrit:Pour le contexte que tu as posé en appuyant sur la touche F2, il s'agit de problématique de mémoires c'est de la pure technique. Nous sommes d'accord que cela n'est pas spécifique à l'arabe. 

Là nous avons écrit seulement du code pour s'échauffer, je ne connais pas ton niveau en java ou en oo. Pour les volumétries plus importantes tu mets en place des stratégies de caching et de pagination. Ce que l'on voit dans Excel Online en somme.

En Java je suis plutôt débutant mais mon "obsession" de la mémoire et de la rapidité me vient peut-être entre autres qu'à une époque je programmais en assembleur des microcontrôleurs et là on essayait de faire le plus court et le plus rapide, la mémoire était limitée et on pouvait compter à l'octet prés et pour la rapidité pareil on pouvait facilement compter le nombre de cycles d'horloge.

Aujourd'hui on est loin de tout ça...

Ibn Nacer a écrit:

Adel Medine a écrit:en fait ce que tu ne comprends pas c'est que la copie dans l'algo remove c'est un luxe qui est facile à retirer et cela est tout autant performant pour peu de lignes de code.

Code:


 static string WithoutVowel(this string targetText)
        {                      
            targetText.ToList().RemoveAll(character=> _vowels.Contains(character));
            
            return targetText;
        }

En dehors de cela je ne vois pas ce que Linq ferait moins bien..

Ah oui je vois le code maintenant. Alors oui on est d'accord on peut éviter la copie c'est là où je voulais en venir et d'ailleurs c'est aussi un peu un truc du genre que j'avais fait en Java :

static String devocalise(String str){

      return str.replaceAll("[\u064e\u064f\u0650]","");

}

Mais encore une fois on peut même éviter carrément de passer par dé-vocalisation...

Ah oui au fait, rappelons quand même que même comme ça à partir du moment où on dé-vocalise il y a des problèmes :

---> Le texte vocalisé sera perdu il me semble car tu reçois targetText en argument et tu le retournes sans les voyelles.

Qu'en penses-tu ?

Ce qui reste vrai pour l'époque et aujourd'hui c'est qu'il faut du code lisible et compréhensible. Certains utilisent l'analogie du journal. Tu arrives le matin au travail tu lis ton journal qui n'est d'autre que ton code. 

La volumétrie et rapidité est toujours une préoccupation aujourd'hui, quand bien même les ressources matérielles/logicielles se sont améliorées, au vu de l'explosion du nombre de données aussi. Il faut juste relativiser.

Oui pour targetText c'est ce que je voulais que tu vois dans le code. Oui la variable perdra au premier tour de boucle ses voyelles. C' est assumé, je n'en ai pas besoin à priori pour obtenir le même résultat que toi. On gagne d'un côté en mémoire, il faut se poser la question de ce qu'on perds. L'avantage déjà c'est que syntaxiquement cela permet aussi de chaîner les appels sans à chaque fois faire une duplication qui peut-être de plusieurs mo ou go. On pourrait écrire myText.WithoutVowel().UneAutreMethodeExtension().UneAutre().Etc()

Normalement cette longue syntaxe devrait attirer ton attention que c'est en train de violer un des patterns fondamentaux qui est "ne parlez pas aux inconnus"; protection des variations. Cela veut dire qu'en chainant comme cela chaque méthode peut renvoyer un objet d'une autre classe ce qui fait qu'entre le début et la fin ce n'est plus le même objet du tout; trop de variations possibles . cela brise le principe de faible couplage aussi. Sauf que ici c'est toujours le même objet c'est une string