tests pré-v2

Fork Bomb · 13/5/2014 19:34:04

lawrent a écrit :

Et sinon, est-ce que quelqu'un s'y connait en optimisation linéaire en nombre entiers? Ça vaudrait la peine d'y jeter un oeil aussi.

N’ayant pas compris, je suppose que ça veut dire qu’on va devoir trouver un(e) prof de maths !

robin_moussu · 13/5/2014 19:35:26

@robipo, À cause ce que tu disais sur les algos génétiques, j'ai un peu réfléchis. Voici le résultat de cette ébauche et en reprenant le vocabulaire des algos génétiques : un individu est un clavier. Son génome est composé de couples {keycodes, valeur}, avec les keycodes fixes, et la valeur un entier (sans doute en code grey pour ne pas avoir une influence trop disproportionnée entre les bits de poids forts et de poids faible). Pour générer son phénotype (la disposition des touches correspondant à son génome), on trie les couples {keycode, valeur}, et ensuit e on place les touches par ordre croissant. Comme ça il n'y a pas de doublon, ça permet de fusionner facilement deux parents, et on peut utiliser les algos génétiques.
Je rappelle que leur avantages sont : à tout moment, on a une disposition de disponible (on peut arrêter quand on veux l'algo), l'algo est par nature distribué (multicoeur, multiprocesseur, multipc), il a un très fort potentiel exploratoire, tout en étant capable de calculer des optimaux.

Et sinon concernant les les tests pour la pré-v2, si ça t'intéresse Robipo, hésite pas à passer sur irc. Et j'avoue que j'aurais besoin de testeur comme toi (comprendre qui ont une très grande vitesse de frappe), pour vérifier que les idée farfelus qu'on a ne sont pas contre productive à haute vitesse.

lawrent · 13/5/2014 20:03:33

Fork Bomb: c'est ça: fr.wikipedia.org/wiki/Optimisation_linéaire

En gros ça consiste à écrire un problème d'optimisation sous la forme d'une fonction objectif à minimiser, étant donné des contraintes.
Exemple:
min x_1 + x_2 - 6 x_3
sous contrainte que
3x_1 - 6x_2 <= 12
x_1 + x_2 + 2x_3 >= 20
x_1 >=0, x_2 >=0, x_3 >=0

La raison pour laquelle on joue avec des fonctions linéaires, c'est qu'il y a des solveurs très étudiés pour. J'ai eu 2 cours là-dessus mais j'avoue que c'est un peu loin…

blen · 13/5/2014 20:33:26

Vu que c'est un algo qu'on ne va faire tourner que quelques fois, pas besoin qu'il soit super-optimisé. D'ailleurs vous pensez vraiment que ça va être si long à faire tourner, assez pour que ça vaille le coup d'utiliser BOINC ?

D'ailleurs je me disais qu'utiliser un langage rapide à coder, comprendre, et modifier serait plus adapté. Comme Python par exemple, ce qui permet de profiter des nombreuses librairies avancées. C'est pas pour rien que les scientifiques utilisent principalement ce genre de langage, et ce qu'on veut faire est typiquement un algo scientifique.

À moins que je me rende pas compte et que ce soit vraiment si long qu'il faille utiliser quelque-chose de plus rapide.

lawrent a écrit :

on pourrait faire un corpus mixte avec:
80% de français
20% d'anglais
ce qui ferait monter la fréquence du w et du k.

Effectivement, il va y avoir de la discussion. Moi je mettrais beaucoup plus d'anglais, voire éventuellement un peu d'autres langues communes en France. Mais je suis biasé, j'écrit au moins autant d'anglais que de français. Ceci dit je pense que c'est le cas de beaucoup de monde.

Il faudrait faire des vraies stats pour régler ça.

Dernière modification par blen (13/5/2014 20:36:57)

ariasuni · 13/5/2014 23:38:02

Robipo a écrit :

Pour que le croisement d'une disposition entière soit intéressant il faudrait que ça ait du sens de mélanger deux bonnes dispositions pour en générer une troisième intéressante. Or, si on prend deux bonnes dispositions (disons le bépo et le bvofrak), déjà je vois pas trop comment on pourrait faire (pour chaque touche on prend aléatoirement du bépo ou du bvofrak ? -> ça va générer plein de doublons, des touches manquantes, ...), bref du gros n'importe-quoi.

On peut lancer l’algorithme génétique pour une seule partie du clavier, et là tu peux inverser les lettres comme tu veux. Et évidemment il faudra essayer plusieurs partitions en deux parties des caractères que l’on veut placer en accès direct sur le clavier. On peut d’abord tester si la partition est équilibrée entre les deux mains pour élaguer.

Robipo a écrit :

Je pense qu'il faut partir d'une approche construction/génération comme on le ferait nous à la main, c'est-à-dire on commence par placer les touches les plus fréquentes aux meilleurs emplacements (genre espace sur la barre, E sur l'index droit ou l'index gauche). Évidemment, il n'y a jamais de « bonne réponse », par exemple l'algo doit mettre le E sur la gauche ou la droite ? On a pas de réponse donc on peut créer deux branches de possibilités, etc etc. Le hic c'est que ça risque de créer des branches de façon exponentielle, pour parer ce problème, il faudrait calculer des stats pour des « embryons » de dispositions et ainsi pouvoir élaguer assez rapidement les débuts de branches non intéressants.

On peut tester digrammes (roulements + alternance) sur la rangée de repos. En ayant un nombre de rangées de repos efficaces déjà calculées, on réduit le nombre de partitions des caractères à placer possible. Eh ouais, j’avais déjà réfléchi à cette idée. Après on peut appliquer le principe plus loin que la rangée de repos, mais faut voir.

«blablabla optimisation linéaire» → je vois pas d’où on aurait une fonction en fait.

blen a écrit :

Vu que c'est un algo qu'on ne va faire tourner que quelques fois, pas besoin qu'il soit super-optimisé. D'ailleurs vous pensez vraiment que ça va être si long à faire tourner, assez pour que ça vaille le coup d'utiliser BOINC ?
D'ailleurs je me disais qu'utiliser un langage rapide à coder, comprendre, et modifier serait plus adapté. Comme Python par exemple, ce qui permet de profiter des nombreuses librairies avancées. C'est pas pour rien que les scientifiques utilisent principalement ce genre de langage, et ce qu'on veut faire est typiquement un algo scientifique.

Je serais plutôt d’accord, mais là non. Faudrait voir si on arrive à élaguer assez, et un langage rapide, ça permet de faire un test sur un plus gros corpus et/ou sur plus de dispositions. Si on ne prend en compte que 30 caractères à placer (pour simplifier, 15 de chaque côté), ça fait 30! soit 2,952328e38 dispositions. Donc (2 et 30 zéros derrières) dispositions de clavier possibles. Ce qui est ÉNORME (là je devrais mettre ça en gras italique souligné police 96 rouge clignotant qui s’imprime sur toutes les imprimantes de chez toi en même temps), ça mettrais juste des années à les générer et surtout à les tester sur des corpus.

Maintenant imaginons qu’on veuille réduire ce nombre. Si on applique ce que j’ai dit plus haut, et qu’on a, prenons un nombre fantaisiste, 20 rangées de repos quasi-optimales, on a un groupe de 22 lettres à partitionner. Ensuite pour une partie de clavier, on choisit une rangée de repos + une partition du groupe de 22 lettres: 2 × 11! / (11! × 11!) = 2 × 11! = 79833600. Déjà beaucoup moins, mais si on doit passer le corpus sur 80 millions de dispos sur un ordinateur, on est pas rendu.

Après faudra qu’on étudie d’autres techniques et qu’on affine les existantes pour réduire le nombre de dispositions potentiellement potables et faire tout ce merdier en parallèle. Après si on arrive à un nombre raisonnable, on peut toutes les tester en faisant tourner le truc H24 sur plusieurs ordinateurs, mais bon ça serait mieux d’avoir un truc qui ne soit pas trop long, parce que si à chaque fois qu’on fait une modif ça prend 48H, on est pas rendu.

lawrent · 14/5/2014 00:24:25

sinma a écrit :

«blablabla optimisation linéaire» → je vois pas d’où on aurait une fonction en fait.

Ben comme fonction objectif tu prends l'énergie de frappe à laquelle ajoutes des facteurs pénalisants en cas de non-alternance de mains gauche-droite ou de digramme difficile.

C'est très simplifié, mais tu peux commencer par définir des variables binaires x_ij telles que x_ij = 1 si le caractère i se trouve sur la touche j; 0 sinon.
Ensuite pour la fonction d'énergie de frappe: E = SUM_ij (f_i·x_ij·w_j) où f_i est la fréquence du caractère i; w_j est l'énergie dépensée pour frapper la touche j.
Ensuite tu as des contraintes évidentes:
* chaque lettre est allouée à une touche: SUM_i x_ij = 1
* chaque touche contient une lettre: SUM_j x_ij = 1
Pour pimenter le modèle tu peux aussi ajouter | F_g - F_d | dans ta fonction objectif où F_g est la fréquence de travail de la main gauche et F_d la fréquence de la main droite.

Après pour inclure un coût de digrammes là-dedans il faudrait probablement jouer avec des variable x_ijkl telles que: x_ijkl = 1 si le caractère i est sur la touche j et le caractère k est sur la touche l.

(Cool! Je pensais pas que je me souvenais si bien de mon cours d'opti )

Dernière modification par lawrent (14/5/2014 00:30:58)

ariasuni · 14/5/2014 00:40:46

lawrent: je voyais pas du tout ça comme ça en fait.

Je me disais juste qu’on faisait la simulation de la frappe de texte, et pour chaque digramme on additionne sa difficulté. On pourrais même faire une liste des digrammes avec leur fréquence et appliquer l’opération à partir de ça, mais je pense que la simulation de frappe peut être intéressante si on veut faire des trucs un peu plus poussés, genre, rth c’est pas du tout facile à faire alors que rt et th ne le sont pas trop.

Tu me diras, on pourrait le faire avec la liste des trigrammes, mais du coup il faut aussi prendre les digrammes à côté pour pas faire de bêtises niveau calcul.

Laurent · 14/5/2014 01:33:59

Robipo a écrit :

Pour que le croisement d'une disposition entière soit intéressant il faudrait que ça ait du sens de mélanger deux bonnes dispositions pour en générer une troisième intéressante.

Si le croisement n’a pas de sens, ça n’enlève pas la possibilité de faire des mutations.

Robipo a écrit :

Je pense qu'il faut partir d'une approche construction/génération comme on le ferait nous à la main, c'est-à-dire on commence par placer les touches les plus fréquentes aux meilleurs emplacements (genre espace sur la barre, E sur l'index droit ou l'index gauche).

E sous l’index est un mauvais choix.

Quelles sont les caractéristiques de l’index :
– il est habile,
– il a un nombre assez important de touches à gérer,
– il est potentiellement utilisé aussi pour la souris (suivant le côté où on l’a mise).

Les deux derniers points impliquent une charge importante pour l’index, pas la peine de lui affecter la lettre la plus fréquente pour aggraver la situation.

Si on met E sous une position de repos (vu sa fréquence, même en considérant beaucoup de paramètres, ce serait étonnant que ce ne soit pas le cas), n’importe quel doigt est capable de taper sur la touche juste sous lui, donc pas de raison d’affecter à un doigt habile un caractère qui est de toute façon sous la position de repos.

D’un autre côté, on ne peut pas exclure que mettre E ailleurs que sous l’index ait des influences négatives sur des critères plus complexes.

La seule manière d’être sûr de ne pas faire de mauvais choix en ratant certaines de leurs implications est d’avoir une fonction d’évaluation qui tienne la route et de ne pas se fermer des voies sur des a priori.

Dernière modification par Laurent (14/5/2014 01:34:41)

Laurent · 14/5/2014 02:03:05

lawrent a écrit :

Ben comme fonction objectif tu prends l'énergie de frappe à laquelle ajoutes des facteurs pénalisants en cas de non-alternance de mains gauche-droite

Il faut arrêter de mettre l’alternance en priorité absolue ; c’était approprié pour les machines à écrire mécaniques.

Test : tapez le plus vite possible (en Bépo) des répétitions de la chaîne « iset » (en Azerty : « dkjf »).

Maintenant, tapez le plus vite possible des répétitions de la chaîne « iest » (en Azerty : « dfkj »). Pour ça, faites un roulement (pour ceux qui n’en font jamais, il faut peut-être s’habituer un peu pour être efficace dessus), c’est-à-dire que vous lancez le majeur et l’index avec un léger décalage pour enfoncer I et E à la suite, puis ne relevez les doigts qu’ensuite ; pareil pour S et T.

Sur quoi allez-vous le plus vite ?
Ce sont les mêmes touches, mais dans le premier cas avec une alternance maximale et dans le second des roulements.

Dernière modification par Laurent (14/5/2014 02:23:40)

lawrent · 14/5/2014 02:25:31

Tant qu'à me citer, autant me citer jusqu'au bout.

lawrent a écrit :

Ben comme fonction objectif tu prends l'énergie de frappe à laquelle ajoutes des facteurs pénalisants en cas de non-alternance de mains gauche-droite ou de digramme difficile.

C'est seulement une idée hein, mais on pourrait mettre une pénalité 0 en cas d'alternance gauche-droite ou de digramme "neutre", une pénalité 1 en cas de digramme difficile (exemple: sauter d'une rangée à l'autre avec le même doigt) et une pénalité -1 en cas de roulement.

Sinon vous pensez quoi de mon modèle? Perso je le trouve propre, élégant, avec une garantie d'optimum global (là où des algorithmes ad hoc ne l'atteignent pas nécessairement). Il faudra juste jouer sur les différents facteurs pondératifs et voir comment la disposition varie. Après en temps de calcul, je sais pas combien ça prendra… le modèle avec les variables x_ij ça devrait prendre un temps raisonnable (à vue de nez, 5min avec un solveur comme cplex ou gurobi), par contre si on veut inclure des contraintes sur les digrammes à mon avis ça risque de monter à 24h de calcul. J'en sais rien, il faudrait tester.

Arathor · 14/5/2014 03:48:19

Je pense comme Laurent que le placement final d’une touche résulte de plusieurs facteurs. L’algo doit bien commencer quelque part, donc il place E et espace sur des touches accessibles. Mais au fur et à mesure qu’il rajoute des symboles, il faut qu’il s’assure de toutes les autres contraintes (hors fréquence du symbole + accessibilité de la touche choisie).

Comme dit Laurent, B et A sont tous les deux bien placés mais beaucoup de monde n’aime pas le digramme BA. Ça montre qu’on ne peut pas placer 10 touches puis 10 autres etc… ça doit rester dynamique.

ariasuni · 14/5/2014 10:26:21

Laurent a écrit :

Il faut arrêter de mettre l’alternance en priorité absolue ; c’était approprié pour les machines à écrire mécaniques.
Test : tapez le plus vite possible (en Bépo) des répétitions de la chaîne « iset » (en Azerty : « dkjf »).

Je suis d’accord, c’est pour ça qu’on doit faire autrement que juste traiter les digrammes je pense. Peut-être qu’en prenant simplement les trigrammes en compte ça marche? Genre pour «iset», on aurait «ise» et «set» et on voit bien que ça pourrait être mieux si c’était sur une main.

Bon après le truc c’est que j’ai l’impression que l’alternance est plus facile à optimiser que les roulements (mais on peut dire bon digramme (donc on compte les roulements) mieux qu’alternance mieux que les mauvais digrammes).

robin_moussu · 14/5/2014 11:39:39

Je vous rappelle juste que les algorithme génétiques sont excellant pour résoudre ce type de problème. Ils nécessitent d'avoir une fonction d'évaluation (dont on a forcément besoin), et d'une fonction pour fabriquer un enfant à partir de deux parents. Celle que j'ai proposé me parait valide. Ce qui est cool, c'est que les algos génétiques n'ont pas besoin de connaitre ce qu'ils doivent résoudre, ce qui fait que l'on n'aura pas besoin de fabriquer des dispositions à la main (il vaut mieux tout générer), et que la validité d'une dispo est de toute façon vérifié (toutes les solution avec un e sur le {w} seront d'office éliminées. De plus, comme je le disais ils peuvent être arrêtés n'importe quand (donc on peut les laisser tourner deux heures pour un test rapide, où 15 jours pour optimiser.

Mais le plus urgent c'est de réaliser la fonction de test.
On pourrait même en avoir plusieurs : une rapide pour élaguer rapidement, et une lente beaucoup plus précise pour déterminer la meilleur du top 10.

Laurent · 14/5/2014 15:29:06

lawrent a écrit :

Tant qu'à me citer, autant me citer jusqu'au bout.

Désolé. Ça fait longtemps que je prêche dans le désert. Ce n’est pas à toi que je peux reprocher de ne pas m’entendre, dans la mesure où tu es dans les derniers arrivés, c’est juste tombé sur ton message.

Après, il va falloir que j’arrive à convaincre que la progression vers l’intérieur n’est pas forcément le mieux (si ce ne sont pas les mêmes touches qui sont impliquées)…

Par exemple, comparez le digramme « iu » (Bépo, « ds » en Azerty) avec le digramme « ai » (Bépo, « qd » en Azerty).

D’une part, la longueur des doigts a une incidence, mais surtout, le fait que les doigts ne sont pas complètement intépendants entre eux musculairement (sauf le pouce) en a une encore plus importante. « Sauter » un doigt n’est pas si immédiat, surtout si c’est l’annulaire (le moins agile). En sauter deux est plus facile (comparez « ai » à « ae »).

Pour deux touches données, effectivement, c’est plus facile vers l’intérieur, mais à mon sens, ça ne vient qu’après la question de quelle paire de touches.

lawrent a écrit :

C'est seulement une idée hein, mais on pourrait mettre une pénalité 0 en cas d'alternance gauche-droite ou de digramme "neutre", une pénalité 1 en cas de digramme difficile (exemple: sauter d'une rangée à l'autre avec le même doigt) et une pénalité -1 en cas de roulement.

C’est à peu près ma vision.

Ce la dit, je dois admettre que je l’ai en partie empruntée à Michael Dickens, le concepteur de la disposition MTGAP.

Je vous invite fortement à lire son article concernant la conception d’une disposition.

robin_moussu a écrit :

Je vous rappelle juste que les algorithme génétiques sont excellant pour résoudre ce type de problème.

Michael Dickens fournit aussi son programme, basé sur un algorithme génétique (sans croisements) et capable d’arriver à un résultat rapidement (mais en ne considérant que des digrammes).

Je n’ai pas encore eu le courage d’essayer de comprendre son programme, mais le faire pourrait nous faire gagner beaucoup de temps (même si on ne décide pas de l’utiliser, tel quel ou modifié, les solutions qu’il a utilisées sont certainement intéressantes — on sait au moins qu’elles fonctionnent).

sinma a écrit :

Je suis d’accord, c’est pour ça qu’on doit faire autrement que juste traiter les digrammes je pense. Peut-être qu’en prenant simplement les trigrammes en compte ça marche?

Faire une simulation sur tout un corpus serait très long.
En prenant des n-grammes (n à déterminer), on peut factoriser le corpus et accélérer énormément l’évaluation d’une disposition par rapport à lui.
Après, plus n sera grand, plus on aura d’informations, mais plus le nombre d’éléments à évaluer sera important (augmentation exponentielle).

Avec n=1, on aurait seulement autant d’éléments à considérer que de caractères différents, mais on n’aurait aucune info sur l’enchaînement des touches, seulement la possibilité de bien placer les caractères les plus fréquents.

Avec n=2, le nombre d’éléments sera déjà plus important, mais on serait capable de dire si l’on a un roulement facile, une alternance, un digramme difficile voire sur un seul doigt…

Avec n=3, le nombre d’éléments sera encore bien plus important, mais on peut vérifier d’autres défauts potentiels. Par exemple, si « ae » (Bépo, « qf » Azerty) est un roulement assez facile et « ei » (Bépo, « fd Azerty) aussi, « aei » (Bépo, « qfd » Azerty) n’est pas terrible.

n=2 est le minimum pour faire quelque chose d’intéressant.
Avec n=3, on améliore l’évaluation, mais au net détriment de la vitesse d’exécution. Il faudrait voir si ça reste dans la limite du raisonnable ou pas.
n=4 serait à mon avis bien trop lourd par rapport à l’amélioration apportée.

robin_moussu a écrit :

Mais le plus urgent c'est de réaliser la fonction de test.

Ce n’est pas tant urgent que crucial. Il faut réussir à ce qu’elle soit à la fois suffisamment pertinente et suffisamment rapide. Sinon, on va ramer pour pas grand chose.

ariasuni · 14/5/2014 15:55:54

Je suis d’accord, n doit être dans {2,3}. Et merci pour les liens, je les étudierais plus en détails plus tard.

lawrent · 14/5/2014 18:11:51

J'ai lu la page du MTGAP, en gros il nous donne toute faite la recette avec laquelle il a créé sa disposition et la carte d'accessibilité sur laquelle il s'est basée. La seule chose qu'on a à faire, c'est de reprendre son programme et de le lancer sur un corpus francophone. (C'est beau le travail qu'un individu peut faire tout seul dans son coin en comparaison d'une communauté entière .) On pourrait bidouiller son algorithme évolutif pour qu'en même temps il tienne compte de la couche AltGr.

Je pense que le choix du corpus est un élément décisif de la V2. On a pas besoin d'analyser des Go de texte de Wikipedia, l'important c'est de trouver un corpus représentatif du texte qu'on tape. Tout au plus quelques Mo je dirais. (À titre d'ordre de grandeur, la Bible au format txt fait 4.3 Mo…) Comme ça la fonction d'évaluation d'une disposition ne prendrait pas 3h. En parlant de corpus, pour tenir compte de l'anglais et de LaTeX on pourrait y ajouter la source .tex d'un poly de maths, non?

Un autre point qui sera crucial, c'est la carte d'accessibilité sur laquelle on veut se baser. Personnellement je n'aime pas la sienne, étant donné qu'avec ma méthode de saisie en V inversé je trouve le {B} et le {J} plus accessibles que le {O} et le {V}.

Robipo · 14/5/2014 18:16:27

Pour savoir quels digrammes/trigrammes sont faciles ou pas, on pourrait aussi essayer d'analyser les fantômes du dactylotest et voir le nombre de millisecondes pour faire le n-gram en moyenne (bon par contre faut être sûr de la dispo qu'utilisent les fantômes..)
Mais ça pourrait ptet faire ressortir des n-grams particulièrement faciles ou difficiles auxquels on aurait pas fait gaffe ou pas pensé (et voir aussi quel ordre de grandeur ça impact, genre entre le trigramme le plus facile à X ms et le trigramme le plus difficile fait combien de X*Y ms)

robin_moussu · 14/5/2014 18:59:59

Bon, pour la fonction de test, je propose cet algo :

------ Préparation à ne faire qu'une seule fois ------
Variable :
NGRAMME = 2 ou 3 (je préfèrerais 3)
TAILLE_CORPUS = beaucoup, disons 1 million (le nombre de lettre dans le corpus)
CORPUS = tableau de caractère contenant un savant mélange entre français, anglais, … en fonction de ce qu'on aura décidé
NOMBRE_CARACTÈRES_TESTÉS = pas mal (cf http://bepo.fr/wiki/Caract%C3%A8res_support%C3%A9s si vous avez envie de compter). On n'est pas obligé de tous les tester, mais je pense que prendre au moins les 150 plus courants pourrait être intéressant. La liste différencie les caractères accentué entre eux (ex : é, e, è sont trois caractères.

OCCURRENCE = tableau de (NOMBRE_CARACTÈRES_TESTÉS ^ L_ DIGRAMME) cases + 1 (les caractères non supportés). C'est un énorme tableau, j'en suis bien conscient. Pour NGRAMME = 3, ça devrait rester acceptable (et j'aimerai bien qu'on teste les trigrammes). Pour gagner un peu de place en mémoire, on peux aussi diminuer NOMBRE_CARACTÈRE_TESTÉS. Si on prend NGRAMME = 3 et NOMBRE_CARACTÈRE_TESTÉS = 100, avec chaque occurrence stocké dans un entier de 32 bits, le tableau ferait donc 1 000 000 d'entiers, soit 8 MO.

debut :
pour i de NGRAMME à TAILLE_CORPUS faire
si (( CORPUS [ i ],CORPUS [ i - 1 ], CORPUS [ i - 2 ] (pour NGRAMME == 3)) sont des caractères connus) alors
incrémenter la case correspondant au N-gramme (CORPUS [ i ], CORPUS [ i - 1 ], CORPUS [ i - 3 ])
sinon
incrémenter la case correspondant à caractère non testé.
fin si
fin pour
enregistrer les résultats, et éventuellement les trier par ordre d’occurrence.
fin

ex : si on parce le corpus «Hé, c'est un pain pas bon», on obtiendra les stats suivantes (avec NGRAMME = 3) :
«Hé,» 1
«é, » 1
«, c» 1
« c'» 1
«c'e» 1
«'es» 1
«est» 1
«st » 1
«t u» 1
« un» 1
«un » 1
«n p» 2
« pa» 2
«pai» 1
«ain» 1
«in » 1
«pas» 1
«s b» 1
« bo» 1
«bon» 1

À part les NGRAMME première lettres et les NGRAMME dernières, elle seront toutes prises en comptes NGRAMME fois. En soit, ce n'est pas grave.
Cette méthode permet également de prendre en compte les débuts et fin de mots.

-----------

calcul du coup de tout les n-grammes
On se base sur les positions physiques des touches, pas du layout.

Cette étape peut également être en partie pré calculé/déterminé ( place prise en mémoire : (NOMBRE_DE_TOUCHE_SUR_LE_CLAVIER ^ NGRAMME) * (COUCHE_MODIFICATRICE ^ NGRAMME), soit environ (50^3) * (6 ^ 3) si on a 50 touches utiles, et les couches normale, maj, altgr, altgr+maj, level5, level5+maj) pour chacun des emplacement possible pour les touches modificatrices (mais ça ils ne devrait pas y en avoir 50 !)

Pour cela, on détermine le coup du n-gramme en question (on prendra en compte la position de chaque touche (ainsi que le coup pour activer les modificateurs si nécessaire), et un bonus si ça s'enchaine facilement, ou un malus si c'est dur).

C'est la partie compliqué, mais de toute façon on devrai la faire quelque soit l'algo utilisé.

---------------

fonction d'évaluation (la seule à effectué à chaque fois)

variable :
NB_ NGRAMMES_PRIS_EN_COMPTE = selon la vitesse à laquelle on veux évaluer, on peux prendre les 1000, 10000, … n-grammes les plus courants dans le tableau calculé à l'étape précédente.

COUP_TOTAL = entier

début
COUP_TOTAL = 0
pour i de 0 à NB_ NGRAMMES_PRIS_EN_COMPTE
On récupère le coup associé pour générer le n-gramme en question calculé à l'étape 2
on multiplie ce résultat par le nombre d’occurrences correspondant à ce n-gramme calculé à l'étape 1
on ajoute la valeur obtenue à COUP_TOTAL
fin pour
fin

---------------------------

L'avantage, c'est qu'on peux faire facilement des tests sur les lettres accentué, sur plusieurs couches, … sans que ça ne soit trop long (c'est une simple suite de multiplication d'entier).

Dernière modification par robin_moussu (14/5/2014 19:07:24)

robin_moussu · 14/5/2014 19:04:12

@Robipo, c'est une très bonne idée d’analyser les fantômes pour récupérer le coup des n-grammes de manière objective.
Si on fait ça, ils faudrait que tout les monde enregistre quelque fantômes en plus, histoire d'avoir plus de stats.

Laurent · 14/5/2014 19:07:05

lawrent a écrit :

J'ai lu la page du MTGAP, en gros il nous donne toute faite la recette avec laquelle il a créé sa disposition et la carte d'accessibilité sur laquelle il s'est basée. La seule chose qu'on a à faire, c'est de reprendre son programme et de le lancer sur un corpus francophone.

À supposer qu’on soit d’accord avec son évaluation et qu’on ne veuille pas tenter de prendre en compte des trigrammes.

lawrent a écrit :

On a pas besoin d'analyser des Go de texte de Wikipedia, l'important c'est de trouver un corpus représentatif du texte qu'on tape.

Ce qui n’est pas la même chose : utilisation de la première de et de la seconde personne, tournures probablement moins sophistiquées, biais sur le sujet de chaque article de Wikipedia…

lawrent a écrit :

Comme ça la fonction d'évaluation d'une disposition ne prendrait pas 3h

Si on factorise en digrammes ou trigrammes, la taille du corpus en texte brut sera nettement moins pénalisante.
Si on veut qu’il soit bien représentatif, le plus dur sera de le créer.

lawrent a écrit :

En parlant de corpus, pour tenir compte de l'anglais et de LaTeX on pourrait y ajouter la source .tex d'un poly de maths, non?

Trop spécifique à mon avis.
Pour moi, il y a d’une part le français, pour lequel il faut optimiser globalement la disposition, et les autres usages, pour lesquels il ne faut pas forcément que la disposition soit très efficace, mais seulement qu’elle ne soit pas pénible.

Supposons que tu mettes du Perl dans le corpus avec une pondération très faible.
Ça va avoir une relative incidence sur l’efficacité pour le français, mais ça ne me garantira pas que $ n’arrive pas sur la touche [²] (Azerty) quand même, vu qu’il ne sert pas en français. Or pour un tel usage, je me fiche un peu de l’efficacité, mais je tiens à ce que ce ne soit pas pénible.

Je pense qu’idéalement, pour les usages secondaires, il faudrait considérer avec une pondération pas trop faible les trucs pénibles (touche [²], digramme sur le même doigt), mais avec une pondération très faible les critères d’efficacité (roulement possible, alternance…).

Autre possibilité : optimiser pour les autres usages après coup en fixant un seuil de dégradation admissible pour la fonction d’évaluation pour le français.

lawrent a écrit :

Un autre point qui sera crucial, c'est la carte d'accessibilité sur laquelle on veut se baser. Personnellement je n'aime pas la sienne, étant donné qu'avec ma méthode de saisie en V inversé je trouve le {B} et le {J} plus accessibles que le {O} et le {V}.

Oui, enfin si tu as une méthode de saisie rien qu’à toi trop différente de la méthode classique (bon, je ne sais pas dans quelle mesure c’est le cas)…

robin_moussu · 14/5/2014 19:11:03

@lawrent Je ne peux pas décider pour tout le monde, mais je pense que ta méthode de saisie ne sera pas retenue, car elle n'est pas compatible avec les claviers ergos (et c'est dommage par ce que j'ai l'impression qu'elle est plus adapté aux claviers 105).

@laurent, c'est sur sa page perso : http://bepo.fr/wiki/Utilisateur:Lawrent … and.C3.A9e

Dernière modification par robin_moussu (14/5/2014 19:12:18)

lawrent · 14/5/2014 20:05:50

Laurent, ça n'a rien de personnel contre toi, mais j'avoue que te voir flinguer mes posts les un après les autres, ça me fatigue

Laurent a écrit :

lawrent a écrit :
En parlant de corpus, pour tenir compte de l'anglais et de LaTeX on pourrait y ajouter la source .tex d'un poly de maths, non?
Trop spécifique à mon avis.
[…]
lawrent a écrit :
Un autre point qui sera crucial, c'est la carte d'accessibilité sur laquelle on veut se baser. Personnellement je n'aime pas la sienne, étant donné qu'avec ma méthode de saisie en V inversé je trouve le {B} et le {J} plus accessibles que le {O} et le {V}.
Oui, enfin si tu as une méthode de saisie rien qu’à toi trop différente de la méthode classique (bon, je ne sais pas dans quelle mesure c’est le cas)…

Laurent dans un autre post a écrit :

lawrent a écrit :
Et si ils sont toujours pas contents, rien ne les empêche de bidouiller leur propre version.
Ha ha ! On me l’a déjà faite !

Laurent · 14/5/2014 20:20:23

lawrent a écrit :

Laurent, ça n'a rien de personnel contre toi, mais j'avoue que te voir flinguer mes posts les un après les autres, ça me fatigue

Pas fait gaffe, c’est les tiens à chaque fois ?

Regarde le bon côté des choses : dans ceux auxquels je ne réponds pas, il y en a où c’est parce qu’ils n’apportent rien d’intéressant…

lawrent a écrit :

Laurent dans un autre post a écrit :
lawrent a écrit :
Et si ils sont toujours pas contents, rien ne les empêche de bidouiller leur propre version.
Ha ha ! On me l’a déjà faite !

On ne peut pas exclure qu’on se retrouve tous les deux (encore !) avec notre propre version…

Hubert · 14/5/2014 20:40:52

Résumé : Post où je brasse les évidences et du rabâché
Où il est question des claviers nouvelles génération : raccourcis avec moins de touches.
------------------

un rappel venu du wiki : j'ai les mêmes conclusiions et doléances. La phrase de fin m'a fait rire.

«Le bépo remplit donc bien son objectif qui est la typographie française et non l'anglais. Si le placement de {Z} et {Ç} reste acceptable pour taper du français, celui de {W} est problématique pour d'autres langues. Et surtout, si l'utilisateur n'a pas un pc105, il peut avoir une mauvaise surprise en essayant le bépo (et potentiellement abandonner l'idée). C'est valable pour les claviers pc101/104, beaucoup de claviers ergonomiques, les pc105 de certains portables… Qu'on le veuille ou non, les constructeurs de ces claviers compriment et/ou déforment le pavé auxiliaire pour gagner de la place.

Certains claviers ergos déportent aussi Z et M. On peut critiquer ce choix, mais il est logique en fait. Ça revient juste à symétriser la partie droite (surchargée sur les pc10X) par rapport à la partie gauche. C'est un progrès ! (qui nous complique la vie, certes). Si c'est pour refuser toute évolution, autant rester en azerty. »

Dans cet article il y est dit grosso modo ce que j'argumente ailleurs.
Il va sortir de plus en plus de clavier symetriques, parfois orthogonaux, avec souvent moins de touches. Tous compatibles Qwerty et Azerty (car ils ont sacrifié des touches très peu usitées), mais tous hélas incompatible BÉPO, «l'utilisateur qui n'a pas un pc105, il peut avoir une mauvaise surprise en essayant le bépo (et potentiellement abandonner l'idée)».

Cordialement

Hubert

Dernière modification par Hubert (14/5/2014 21:20:51)

yeKcim · 15/5/2014 09:22:07

idée : faire une liste des défauts du bépo (liste variable selon chacun évidemment) pour éviter de faire les mêmes erreurs (ça n’empêchera pas d’en faire d’autres…). Pour ma part, je liste surtout :
→ w trop loin
→ < et > impossibles à une main donc faiblement accessibles
→ altgr uniquement à droite (lié à la remarque précédente ?)

il y en a surement plein d’autres, mais comme ça ce sont les premiers trucs qui me viennent à l’esprit. L’idée de liste vous semble pertinente ?

Forum bépo

#26 13/5/2014 19:34:04

Re : tests pré-v2

#27 13/5/2014 19:35:26

Re : tests pré-v2

#28 13/5/2014 20:03:33

Re : tests pré-v2

#29 13/5/2014 20:33:26

Re : tests pré-v2

#30 13/5/2014 23:38:02

Re : tests pré-v2

#31 14/5/2014 00:24:25

Re : tests pré-v2

#32 14/5/2014 00:40:46

Re : tests pré-v2

#33 14/5/2014 01:33:59

Re : tests pré-v2

#34 14/5/2014 02:03:05

Re : tests pré-v2

#35 14/5/2014 02:25:31

Re : tests pré-v2

#36 14/5/2014 03:48:19

Re : tests pré-v2

#37 14/5/2014 10:26:21

Re : tests pré-v2

#38 14/5/2014 11:39:39

Re : tests pré-v2

#39 14/5/2014 15:29:06

Re : tests pré-v2

#40 14/5/2014 15:55:54

Re : tests pré-v2

#41 14/5/2014 18:11:51

Re : tests pré-v2

#42 14/5/2014 18:16:27

Re : tests pré-v2

#43 14/5/2014 18:59:59

Re : tests pré-v2

#44 14/5/2014 19:04:12

Re : tests pré-v2

#45 14/5/2014 19:07:05

Re : tests pré-v2

#46 14/5/2014 19:11:03

Re : tests pré-v2

#47 14/5/2014 20:05:50

Re : tests pré-v2

#48 14/5/2014 20:20:23

Re : tests pré-v2

#49 14/5/2014 20:40:52

Re : tests pré-v2

#50 15/5/2014 09:22:07

Re : tests pré-v2

Pied de page des forums