Re: Projet de dictionnaires arabes

par Adel Medine Jeu 25 Déc - 1:16

J'essai juste de t'avertir en ce qui concerne le sujet des performances et des tests. Ce que je voulais que tu notes, en dehors de l'écriture de ton algorithme qui est bon, c'est l'expressivité du code. C'est à dire avec combien de lignes et quelle facilité de lecture et compréhension cela suffit pour atteindre un résultat acceptable.

Oui bien sûr c'est normal d'écrire des classes et des méthodes adaptées pour l'arabe. Cela dépend de ce qu'on souhaite faire et de ce que l'on connaît à ce moment là aussi.

par Adel Medine Jeu 25 Déc - 1:21

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 ?

par Ibn Nacer Jeu 25 Déc - 1:23

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...

Adel Medine a écrit:Oui j'ai ce lien http://ideone.com/sBtfgd

D'un point de vue algorithmique cela semble être pareil, une complexité N². La différence est sur l'allocation mémoire et dans ta méthode tu crées aussi une copie au départ

Code:
char[] src = source.toCharArray();

Oui tout-à-fait ! Et justement je t'en avais parlé, je te remets le message (regarde en particulier le dernier paragraphe) inchâ-a Allâh :

Ibn Nacer a écrit:
Ibn Nacer a écrit:Voilà une mise en évidence du problème : http://ideone.com/gBlZfx

Voilà j'ai réécrit la fonction de sorte qu'elle ignore les trois voyelles brèves : http://ideone.com/sBtfgd

Ça a l'air de fonctionner alhamduliLlâh.

Bien sûr il faudrait normalement qu'elle ignore aussi les autres signes diacritiques comme la cheddah et le sukûn par exemple... Il suffit de rajouter leur code point dans le "ou logique"...

Dans le cas où la chaine source dans laquelle on fait la recherche est longue il vaudrait peut-être mieux ne pas transformer le String en tableau de Char et travailler directement sur le String avec la méthode char java.lang.String.charAt(int index).

C'est à voir inchâ-a Allâh.

Wa Allâhu a'lam.

par Adel Medine Jeu 25 Déc - 1:34

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.

par Adel Medine Jeu 25 Déc - 1:38

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.

par Contenu sponsorisé