tests pré-v2

Mimoza · 15/5/2014 09:44:41

"{}" dans la même position que "<>"
le ";" m'est plus utile que la ","
Bref pour taper du code c'est pas pratique

yeKcim · 15/5/2014 10:04:38

question dont je ne trouve pas la réponse : pour le groupe de texte permettant de définir les touches les plus fréquente, est-ce que la méthode est de prendre des textes dans pleins de langue et d’appliquer des coefs ou c’est une autre méthode qui est appliquée ? avec cette méthode le ç s’éloigne surement au profit du w par exemple…

yeKcim · 15/5/2014 10:07:40

Autre souci : je n’utilise jamais ' mais toujours ’ mais c’est sûrement parce que je ne dev pas beaucoup. Peut-être faudrait-il faire un topic pour lister… ou un système de vote pour indiquer d’une façon ou d’une autre combien de personnes trouve chaque point gênant…

ariasuni · 15/5/2014 11:36:43

J’avais commencé à lister les défauts et c’est devenu ça: http://bepo.fr/wiki/Utilisateur:Sinma/V2/Symboles

Pour les défauts, j’ai commencé un sujet ici: http://forum.bepo.fr/viewtopic.php?pid=9135#p9135

Laurent · 15/5/2014 13:36:51

yeKcim a écrit :

→ < et > impossibles à une main donc faiblement accessibles

En quoi est-ce utile qu’ils soient faisables à une main ?

Pour ma part, je les ai mis en AltGr mais sous la position de repos (je peux même faire un roulement pour <=, >= voire pour <>, <=>, spécifiques à Perl) : je préfère conserver les caractères utilisés pour le français au maximum en accès direct pour ne pas freiner ma frappe, alors que pour les signes fréquents dans les langages informatiques, j’ai cherché en priorité à ce qu’ils soient bien placés pour améliorer le confort. Les langages informatiques nécessitent une précision qui demande de toute façon plus d’attention et donc moins de vitesse.

yeKcim · 15/5/2014 14:48:55

pour coder en html c’est huper pénible en comparaison d’un azerty
dans inkscape le raccourcis clavier ctrl+< et ctrl+> est chiant à faire

là comme ça je ne vois pas d’autres remarque

lawrent · 15/5/2014 17:43:50

Pour en finir une bonne fois pour toutes avec les trigrammes.

Si on veut faire comme pour le MTGAP, ce dont il a besoin, c'est:
- un corpus représentatif sur lequel évaluer la disposition
- une carte d'accessibilité
- une carte d'accessibilité pour les digrammes
- une carte d'accessibilité pour les trigrammes
la fonction d'évaluation alors, elle passe le corpus à travers la moulinette et elle compte les points en fonction des cartes d'accessibilité et à la fin elle divise par le nombre de caractères corpus pour avoir une valeur normalisée.

(et pour ceux qui n'ont pas lu la page du MTGAP, son algo évolutionnaire il consiste à chaque génération à prendre toutes les dispos de la précédentes, faire un swap aléatoire entre 2 touches sur chaque dispo et exclure la moitié des dispositions qui score le plus haut.)

ce qui nous fait 4 paramètres sur lesquels on peut jouer:
- un fichier txt externe
- un tableau à 35 entrées (si on se limite à la région centrale)
- un tableau à 35² entrées
- un tableau à 35³ entrées
où on doit encoder nous-mêmes les valeurs de ces 3 tableaux parce que c'est eux qui définissent les critères que satisfera la dispo finale. Pour la carte d'accessibilté on peut encore se permettre d'encoder toutes les valeurs à la main, pour les digrammes et les trigrammes si on veut pas devenir dingue je proposerais qu'on se limite à une échelle à 3 ou 5 valeurs: (très bon), bon, neutre, mauvais, (très mauvais). Il faudra faire des essais pour voir à quelle pénalité exactement ça correspondra.

Une fois qu'on a ça on n'a plus besoin de se préoccuper avec des règles subjectives comme "les roulements vers l'intérieur ça fait +1, les roulements vers l'extérieur ils sont pas bons, les trigrammes sur 2 lignes on les aime pas" qui s'écriraient comme un interminable if-then-else.

Note qu'on pourrait très bien écrire un petit programme qui écrirait les cartes d'accessibilité pour nous, parce qu'il y aura forcément des patterns communs à plusieurs di/trigrammes: par exemple, tous les digrammes qui incluent la même main et un saut de ligne, on les aime pas—sauf exceptions. Et il y aura beaucoup de di/trigrammes neutres dans la liste…

Dernière modification par lawrent (15/5/2014 17:49:23)

robin_moussu · 15/5/2014 17:53:12

> Une fois qu'on a ça on n'a plus besoin de se préoccuper avec des règles subjectives comme "les roulements vers l'intérieur ça fait +1, les roulements vers l'extérieur ils sont pas bons, les trigrammes sur 2 lignes on les aime pas" qui s'écriraient comme un interminable if-then-else.

Si on fait des trigrammes (ce que j'aimerais), il est impossible (faute de temps humain) de tous les écrire. Il faut donc les générer, et du coup pour les générer il faut avoir cette liste subjective.

robin_moussu · 15/5/2014 21:53:07

j'ai créé un framapad http://lite4.framapad.org/p/4kP4f5nj8z suite à la discussion sur ce thread http://forum.bepo.fr/viewtopic.php?id=1020. Je n'ai pas de temps de fouiller ce thread pour voir si il y a des trucs à rajouter en provenance de celui-ci. Si une bonne à le temps de la faire c'est cool.

lawrent · 15/5/2014 23:54:23

Quelques idées pour la partie algorithmique:

- Convertir le corpus en une longue chaine de chiffres (0 est un chiffre représentant les frappes non-incluses dans la liste des caractères à placer: \n, \t, ï, û, …, etc.).
- représenter une disposition comme une permutation D dans S_35 (ou S_x avec x le nombre de touches sur le clavier à décider).
- évaluation d'une disposition = Eval(D(corpus)). En d'autres mots:
-- D est une fonction : Corpus in {0,35}^L -> Séquence de touches in {0,35}^L
-- Eval est une fonction qui calcule la pénalité associée à une séquence de touches

tout ça sera codé en C, pour des raisons de vitesse de calcul (évaluer le corpus risque d'être très long…)

--- OU ALORS ---

étant donné que la fonction d'éval ne fait que compter le nombre de 1-grammes, 2-grammes et 3-grammes dans le corpus traduit, on peut résumer le corpus en 3 tables:
- tab1[x] : vecteur qui compte combien de fois la lettre x apparait dans le texte
- tab2[x][y] : matrice qui compte combien de fois le digramme xy apparait dans le texte
- tab3[x][y][z] : tenseur qui compte combien de fois le trigramme xyz apparait dans le texte
et les occurrences sont divisées par le nombre de caractères, histoire de normaliser tout ça

auxquels correspondent 3 tables de paramètres:
- coeff1[x] : la pénalité associée à la touche x
- coeff2[x][y] : la pénalité associée à la succession de touches xy
- coeff3[x][y][z] : il faut vraiment que je l'écrive?

La fonction de cout devient alors rapide à évaluer:
COUT = SUM_i D(tab1[i ]) * coeff[i ]
+ SUM_ij D(tab2[i ][j]) * coeff2[i ][j]
+ SUM_ijk …
ce qui doit fait quelque chose de l'ordre de 100,000-200,000 flops

robin_moussu · 16/5/2014 01:28:49

@lawrant : ce que tu dis est pertinant mais je ne peux m'empécher de relever « tout ça sera codé en C »
Alors là pas question. Je sais faire du C, mais c'est un langage à peine mieux que l'assembleur Si on veux des perfs, on prend du c++, et en plus on a (ceux qui veulent coder) des connaissances en c++.

Le prend pas mal, mais je suis trop fatigué pour ne pas mordre au troll !

lawrent · 16/5/2014 01:35:10

Robin: je le prends pas mal à la base j'avais écrit toutes ces notes d'un seul jet pour moi-même. Le "ou alors" a marqué le moment où j'ai changé d'avis et j'ai pas eu la motivation de réécrire proprement mes notes avant de les poster sur le forum. En pratique vu que la fonction d'évaluation sera relativement légère j'écrirai probablement tout ça en Matlab, langage que je maitrise mieux. Après ça reste mes choix personnels de bidouilleur qui veut faire ça dans son coin.

damien thiriet · 17/5/2014 22:27:00

Je signale juste un point de statistique concernant la taille du corpus: à partir du moment où l’on atteint 1000 unités, un échantillon aléatoire ne donne une marge d’erreur que d’1% par rapport à toute la population. C’est pour ça que les sondages utilisent cet échatillon.

Pour les faibles taux, il faut un échantillon plus large, mais pas besoin d’un corpus gigantesque alourdissant le calcul, 1Mo suffirait largement… Ce qui ne résoud certes pas la question de sa composition.

Arathor · 17/5/2014 22:36:29

Pas le temps de tout lire, mais par rapport au dernier message : une marge d’erreur de 1%, ça passe pour les sondages politiques mais c’est inadmissible dans notre cas. Cf tous les caractères qui gravitent entre 1 et 2 %, voir moins de 1 %.

La conception et les calculs prendront le temps qu’ils prendront, on est là pour faire les choses correctement.

damien thiriet · 18/5/2014 11:00:27

Je suis d’accord, mais avec un corpus de quelques megas, on a largement suffisamment pour que les marges d’erreur des caractères à faible occurence soient réduites au maximum. 1% d’erreur, c’est un corpus de 1 à 4 ko (en prenant l’hypothèse qu’une lettre = 1, 2 ou 3 octets. Les cas à 4 octets doivent être rares, non?). Donc quelques mégas sont largement suffisants à mon sens.

ariasuni · 18/5/2014 15:17:49

Au pire on fera des tests et on fera des ajustements pour voir vers quelle taille on a un rapport précision/taille suffisant.

lawrent · 23/5/2014 15:06:44

Notons au passage qui si on implémente ce que j'ai proposé, on ne devrait analyser le corpus qu'une seule fois. J'ai déjà commencé à bidouiller 2-3 lignes de code, Matlab prend 0,8sec pour sortir les fréquences des caractères présents dans les 4Mo de la Bible. Bref, tant qu'on reste en dessous de 100Mo de corpus on devrait être bon

Je rejoins l'idée générale: la composition du corpus est bien plus importante que sa taille.

ariasuni · 23/5/2014 15:22:44

Le problème de temps se posera surtout au moment de tester la disposition pour lui donner un score.

yeKcim · 23/5/2014 16:18:55

lawrent : du coup il y a combien de @ dans la bible ?

Forum bépo

#51 15/5/2014 09:44:41

Re : tests pré-v2

#52 15/5/2014 10:04:38

Re : tests pré-v2

#53 15/5/2014 10:07:40

Re : tests pré-v2

#54 15/5/2014 11:36:43

Re : tests pré-v2

#55 15/5/2014 13:36:51

Re : tests pré-v2

#56 15/5/2014 14:48:55

Re : tests pré-v2

#57 15/5/2014 17:43:50

Re : tests pré-v2

#58 15/5/2014 17:53:12

Re : tests pré-v2

#59 15/5/2014 21:53:07

Re : tests pré-v2

#60 15/5/2014 23:54:23

Re : tests pré-v2

#61 16/5/2014 01:28:49

Re : tests pré-v2

#62 16/5/2014 01:35:10

Re : tests pré-v2

#63 17/5/2014 22:27:00

Re : tests pré-v2

#64 17/5/2014 22:36:29

Re : tests pré-v2

#65 18/5/2014 11:00:27

Re : tests pré-v2

#66 18/5/2014 15:17:49

Re : tests pré-v2

#67 23/5/2014 15:06:44

Re : tests pré-v2

#68 23/5/2014 15:22:44

Re : tests pré-v2

#69 23/5/2014 16:18:55

Re : tests pré-v2

Pied de page des forums