Discussion:Méthodologie

Texte en vrac de l'ancier wiki pour rédiger l'article

<Shildark> Le ¡ c'est pas un caractère francophone, s'il est sur le clavier, il sera là où on peut, mais on se casse pas la tête pour des caractères non francophones

mise à plat pour les caractères spéciaux :

   * les caractères non-français accessibles par touche morte uniquement ;
   * la homerow en AltGr est réservé aux caractères pour programmeurs (sauf pour æ ù € ç) ;

Pour satisfaire une majorité de personnes, je propose que nous nous mettions d'accord sur une procédure afin d'avoir la liste des caractères, chiffres et symboles utilisés le plus souvent.

Par exemple étant programmeur je souhaiterais voir dans les tests la prise en compte de cela avec bien sûr un coefficient puisque tout le monde ne programme pas.

De plus pour valider un test il faut prendre en considération ce que les gens utilisent le plus. Dans le cas de la programmation il est évident que prendre le langage Lisp n'est pas réaliste car parmi la somme des programmeurs bien peu l'utilisent.

Je propose donc de faire des tests sur ces différentes catégories :

1. Textes personnels (lettres, rapports) 2. Textes d'auteurs 3. Comptabilité (document comptable, tableur) 4. Programmation (langages C/C++, Delphi, Visual Basic, JAVA, PHP, Python)

À vous de proposer d'éventuelles autres catégories.

Ensuite il faudra donner des coefficients pour chaque catégorie. Par exemple: 1. 70% 2. 10% 3. 10% 4. 10%

Créer un corpus

Thomas Tempé Perso, je mettrai probablement 90% de français (dont 40% de texte littéraire, 30% de mail et 30% de pages web) et 10% de code (dans des langages choisis selon un sondage de popularité et ma propre appréciation).

Fabien JOBIN Heu histoire de commencer un autre troll, prenons nous aussi quelques textes en anglais (avec un rapport faible par rapport à l'ensemble) pour ne pas avoir une disposition trop anti américaine, heu enfin anti anglo-saxonne. On peut considérer par ailleurs que le fait d'incorporer des langages informatique suffit car ils sont en général en anglais. Avec quelques textes anglais : Français 80 % (texte d'auteur 30%, texte personnel 40%, mail 15%, page web 15%) Code 15 % (C/C++/Java 25%, PHP 20%, Perl 15%, VB 25%, Delphi 15%) Anglais 05 % (texte d'auteur 30%, texte personnel 40%, mail 15%, page web 15%)

Sans texte anglais : Français 85 % (texte d'auteur 30%, texte personnel 40%, mail 15%, page web 15%) Code 15 % (C/C++/Java 25%, PHP 20%, Perl 15%, VB 25%, Delphi 15%) Dans un autre mail : Personne1: Texte littéraire : 35 % : 2 000 000 caractères : e 10%, s 7%, etc. Texte perso : 40% : 50 000 caractères : stat des textes perso Mail : 20% : 5 000 caractères : stat mail Codes sources : 5% : 50 000 caractères : stat

Nicolas C.\\ Pour ma part, au niveau des proportions je pencherais plutôt pour ces Proportions :

 Français 90 % (texte d'auteur 25%, texte personnel (rapport par exemple) 45%,

mail/web (rendu final, pas source)/IRC 30%)

 Code 10 % (C/C++/Java 30%, PHP/Perl 20%, web (HTML/XML) 15%, LaTeX

15%, Pascal/VB/Delphi 15%, Bash 5% (pas le bash_history car beaucoup d'utilisation de complétion)) En ce qui me concerne je pense que le code contient suffisamment d'anglais (structure, variable, commentaires) pour ne pas devoir en rajouter.

Pourquoi mixer différents corpus : Si on veut que ça convienne à tout le monde il faudrait que tous les français fassent leur corpus, mais c'est impossible. Donc un des pires c'est de faire chacun son propre corpus qui reflète le plus possible se qu'il tape avec son clavier ou se qu'il pense être le mieux pour tout le monde. En faisant ainsi chacun a un certain poids mais le clavier final ne Ne dépend de personne en particulier. Évidement il faut quand même penser aux autres, par exemple je ne vais pas mettre 80% de code C et 10% de texte par ce que j'écris plus de C que de texte. Il faut garder à l'esprit qu'au final le clavier doit être un clavier massivement francophone utilisable par une grande majorité de personne allant de la secrétaire qui tape des lettres, au comptable qui jongle avec les prix et les devisent, en passant par des informaticiens et internautes au langage barbare (c koi 1 barbare,:-), asap, lol, imho, etc. ).

"Universalité" du corpus Ben oui, et qui osera proposer un panel à la louche ? Je suis bien trop petit pour savoir ce que fait un tel avec son ordi, je sais tout juste s'il tape avec ses dix doigts (ce qui est pourtant un préalable pour avoir le loisir de pinailler sur la dispo des touches comme on le fait :-)). Les mots peu courants le sont, leur influence est donc atténuée par du français moderne; mais là encore, les vieux mots ont une gueule de mot français : pas très éloignés du latin, des préfixes/suffixes classiques, etc. -- et encore une fois ce ne sont pas les mots qui comptent, mais les lettres je ne suis pas loin de croire que ce débat stérile sur les ingrédients du "bon" corpus sont vains : la crainte du mauvais choix fait tourner la patate et ce n'est pas la tête dedans que la solution sera trouvée, car tout le monde a raison dans ses choix puisqu'ils sont EQUIVALENTS. Quand vos statistiques commenceront à pleuvoir, on s'apercevra que les différences sont minimes : le juste prix pour 'e' est à mon avis de l'ordre de 10%, moins de 1% pour le "w", and so on.

Arrivée de Nicolas C.

Calcul de disposition des touches :

Voici ce que je propose comme algorithme pour répartir les touches (c'est ce qui me semble personnellement le plus logique) :

- Statistiques sur les symboles.

 - Créer un corpus (avec les proportions de texte français / mail / code

données dans les anciens mails).

 - Calculer les fréquences des symboles simples (pas de distinctions sur la

casse des lettres), des digrammes (et des trigrammes ?).

 - A partir des fréquences des lettres (y compris accentuées), chercher les

lettres accentuées qui seront mappées directement sur les 48 touches à accès direct et en déduire les touches mortes (je pense que l'azerty est plutôt bien fait à ce niveau : éèàù en direct, ^ et ¨ en touche morte, et d autre en touche morte sur altgr (~ ? `)).

 - Ensuite, reprendre le corpus et remplacer tous les symboles obtenus via

touche morte par la touche morte suivi de la lettre afin d'avoir des meilleures données concernant la façon dont ça a été tapé plutôt que le résultat.

 - Refaire les statistiques.
 - Vérifier que y'a pas d'incohérences qui soient apparues (genre une touche

morte qui remonte dans les statistiques et fait sortir une lettre accentuée du top 42 (48 - 5 lettres accentuées en accès direct - 1 touche morte).

 - Prendre les 48 touches les plus fréquentes (hors chiffres si on les met en

"shift") pour les mapper en accès direct (si des lettres rares comme w n'y sont pas, on les mets quand même, sinon ca va être trop laid un keymap avec un y en altgr+shift ;) ).

- Placement.

 - La méthode que je pense le plus adaptée serait de déterminer la "facilité"

d'accès aux touches, parce que même si on tape comme une dactylo, il reste néanmoins indéniable que (sur un clavier azerty) le f et le j sont plus facile d'accès que le ^ et le a. (à ce sujet je n’arrive pas à accéder à la carte sur le wiki, qq1 l'a t il toujours).

 - Le principe du keylogger (de vitesse de frappe) me semble bon, mais il reste

à voir si les résultats sont réellement exploitables, ce dont je doute légèrement.

 - Plutôt que de partir sur une analyse de ce type, je pensais plutôt à une

répartition naturellement plus rapide pour la frappe. Donc sur une répartition des symboles de façon à faciliter la frappe des digrammes, basé sur les remarques très générales :

   - C'est plus facile si c'est sur deux mains différentes
   - Si c'est sur la même main c'est plus facile si c'est sur deux doigts

différents et que la direction de la suite des deux lettres va vers le centre du clavier (plus facile de taper mlkj que jklm (clavier azerty))

   - Je ne sais pas trop quoi tirer comme conclusion sur les trigrammes à part

le fait que chaque digramme doit vérifier les propriétés précédentes.

- Fonction de fitness.

 - On peut dire qu'une entorse à ces règles pénalise le keymap (on rajoute du

malus par exemple).

 - On simule le corpus sur un keymap et on calcule une fonction de fitness (de

type lower is better), ceci sur différents keymap

 - On applique un algorithme génétique là-dessus (pour ce qui est du recuit

simulé je ne connais pas le principe).

En revanche une question qui se pose : sur quels keymap partir ? Azerty ? Qwerty ? dvorak-fr de M Leboutte ? Avec ses variantes diverses données par différentes personne sur la ml ? des mapping fait à vue de nez qui semble plus ou moins ergonomique ? Une autre question : évaluation des malus sur les entorses aux règles. A moins de faire des statistiques de vitesse d'accès (sans doute trop variable), ça risque d'être à la louche et potentiellement foireux niveau influence des coefficients. En revanche, comme il y a peu de types d'erreur (mauvaises main ou mauvais sens si c'est sur la même main, le 1er étant plus pénalisant que le second, on peut prendre par exemple respectivement 1 et 2 comme valeur (vu que le deuxième problème est le premier problème auquel on rajoute l'erreur de sens).

Sinon je rappelle qu'une recherche combinatoire exhaustive est utopique (48 symboles à mapper sur 48 touches, on n’a pas fini...)

Toujours sur l'arrivée de Nicolas C. Je reviens rapidement sur un ancien mail où Thomas Tempé parlait de la méthode lourde et de la méthode du vote. Personnellement je pense que la méthode du vote n'irait pas forcément plus vite. Même si on est peu à voter, je sens que ça risque de partir en troll à n'en plus finir et qu'avant d'arriver à un clavier qui plaise à tout le monde on va probablement passer autant de temps que via une méthode lourde.

Je penche plutôt pour une optique d'une méthode qui essaye d'être la moins lourde possible afin d'aboutir à un résultat sans avoir à attendre 10 ans...

Suite aux problèmes qui sont apparus lors de recherche de solutions pour résoudre le problème de l'association de touche, on voit qu'en gros on a plusieurs étapes :

Créer corpus
Générer des statistiques de fréquences de symboles
Calcul coûts des touches
Évaluer un clavier
Évoluer un clavier

Les deux premiers points se feront tant bien que mal. Le troisième pose problème, les quatrième et cinquième étant encore pire. Le problème de l'algorithme gen reste tout de même le croisement de deux claviers en cherchant à obtenir un clavier meilleur, ce qui n’est pas franchement évident. L'autre problème étant que l'algorithme ne fini pas. Si pour les couts des touches, on reste sur la carte du clavier donnée sur le corpus, j'ai pensé à une solution de recherche combinatoire qui pourrait se faire dans un temps raisonnable. En effet, si on ne tient pas du tout compte (pour l'instant) des digrammes et trigrammes, un bon clavier pourrait être obtenu en associant les symboles les plus fréquents aux touches de moindre coût. Or, si on s'en tient à la carte du wiki, plusieurs touches ont le même coût (5 pour 48 touches). A partir de là j'ai eu l'idée suivante : On prend la première série de touches (8), autant de symboles les plus fréquents, et on teste toutes les combinaisons (8! = 40320), pour chaque on calcul le coût, non pas d'accès car toutes les variantes obtiendront la même note, mais on tient alors compte des digrammes. On obtient alors un placement des 8 symboles les plus fréquents, et ensuite on s'occupe de la seconde catégorie, en considérant les 8 1ers symboles mappés par le résultat obtenu pour la première partie, et ainsi de suite... Après réévaluation de la carte, j’obtiens 5 catégories de 8, 11, 12, 3, 14 touches chacune, ce qui fait un nombre de keymap à évaluer inférieur (car comme on cherche à minimiser une somme, on peut zapper des cas) à 8! + 11! + 12! + 3! + 14! ~ 87.10^9 (C’est largement plus raisonnable que les 48! ~ 10^61 initiaux). S'il s'avère que les calculs prennent trop de temps, on est toujours à même de voter les emplacements pour la dernière série, dont l'influence sera relativement faible je pense, on descendrait donc à 518 millions de cas. Je pense que c'est largement réalisable. Au sujet des digrammes, comme leur rôle est de déterminer l'alternance des mains, je pense qu'il est préférable, non pas de calculer les fréquences des digrammes, mais plutôt pour chaque paire de symbole, la différence entre :

le nombre de séquences où les 2 symboles apparaissent à un nombre impair

d'écart (1 pour les digrammes, 3 pour les quadri grammes...)

et la même chose pour les nombre pair (2 pour les trigrammes ...)

Ca permet de voir la tendance globale que deux symboles auraient à être tapé par la même main ou deux mains différentes. De plus, si on travaille sur les nombre d'occurrences, on n’a pas à mettre de coefficients sur les résultats, donc pas de coefficients choisis à la louche qui influenceraient le résultat final.

En conclusion, je pense que si on suit cette voie, évidement on ne calcule pas tous les cas (loin de là), mais on calcule ceux qui auront le plus tendance à donner de bons résultats. On sera toujours à même de faire quelques mutations par la suite. Le tout avec un calcul exhaustif sur un sous ensemble de résultats.

Est-ce que quelqu'un a déjà étudié l'effort qu'il faut pour frapper chaque touche et défini une sorte de coefficient de pénibilité pour chacune d'elles? Si l'on combinait ces coefficients de pénibilité avec les fréquences d'apparition des lettres en français, on pourrait calculer une première approximation d'un clavier ergonomique. Ce genre de travail a-t-il déjà été mené?

Oui et non. Quelqu'un avait fait une carte qui indiquait les touches les plus faciles d'accès et les touches les moins faciles d'accès. http://gpl.insa-lyon.fr/Dvorak-Fr/CarteDuClavier Je pensais attribuer à chaque touche une valeur numérique reflétant l'effort de son actionnement. Si on multiplie le coefficient de pénibilité de chaque touche avec la fréquence de la lettre en français et si l'on additionne tous les produits, on obtient un coefficient de pénibilité du clavier. Cette valeur pourrait avoir une utilité pour comparer différentes dispositions de manière simple. Le problème c'est qu'il y a 48 touches, donc 48 coefficients à trouver, et je pense que la moindre variation risque d'avoir une influence non négligeable.

Actuellement je travaille toujours sur la création d'une disposition à partir des statistiques, et non sur l'évaluation d'une disposition. La méthode que j'utilise n'utilise pas de coefficients, juste la carte présente sur le wiki (aux commentaires près et à quelques modifications à cause des complexités de calculs)

> AMHA, il est préférable qu'un clavier donne une impression de logique, ce qui facilite l'apprentissage. Pour certains symboles relativement peu utilisés, on peut utiliser une organisation logique (par exemple, on va peut-être pas faire une fréquence des chiffres pour savoir comment les placer, on va plutôt garder l'ordre numérique) Mais pour les symboles arrivant fréquemment, je ne pense pas que ce soit une bonne idée. Après, c'est peut-être un peu plus difficile à apprendre, mais je pense que la difficulté viendra principalement du changement des lettres. Et ça, on est obligé de le changer si on ne veut pas d'un azerty :)

Sinon, j'ai fini de coder un programme qui calcule un clavier à coût minimal à partir de mes statistiques. Il calcule par bloc (ceux de http://gpl.insa-lyon.fr/Dvorak-Fr/CarteDuClavier), et là j'ai calculé que le premier : les 8 touches de base J'obtiens donc ceci : T O E A S N R I Au lieu de (pour l'azerty) Q S D F J K L M Dvorak fr O A U E S T N D

Ce qui m'inquiète c'est le temps de calcul (7' pour une étape de 8 touches, donc probablement 2jours pour 12 touches...)

Marco wrote: > Nicolas Chartier wrote: >> On pourrait donc prendre 9 7 5 3 1 0 2 4 6 8 comme ordre par exemple >> (d'ailleurs vu que celle 3 chiffres (1 2 0) sont dans les 48 >> premiers symboles, je les ai tous mis en accès via shift. > Cette idée peut séduire... mais pour un clavier expressément réservé > aux hackers patentés. > En tant qu'utilisateur lambda non informaticien, un tel clavier me > dépasserait complètement. C'était juste une idée hein >> Si on a pas A sur shift + a ca va être galère, mais si ce n’est pas ? >> qui est sur shift + ? perso ca me gêne pas. > D'autant plus que les gens sont tout de même habitué à avoir une > rangée du haut avec des symboles différents 123456 > &?"'(-

Oui, les chiffres seront sur la rangée du haut, en shift. Pour ce qui est des symboles, ca sera aussi possible, y'a juste 2 symboles à remonter par rapport aux statistiques. >> Il calcule par bloc (ceux de >> http://gpl.insa-lyon.fr/Dvorak-Fr/CarteDuClavier), et là j'ai calculé >> que le premier : les 8 touches de base >> J'obtiens donc ceci : >> T O E A S N R I >> Au lieu de (pour l'azerty) >> Q S D F J K L M >> Dvorak fr >> O A U E S T N D >> > Sinon, j'ai fini de coder un programme qui calcule un clavier à coût > minimal à partir de mes stats

> Les fréquences ne sont pas tout. Un facteur tout aussi important est > l'alternance des mains: quand on tape "tutu" sur un clavier AZERTY, la > main droite se prépare à taper le "u" pendant que la main droite tape > le "t".

On a du mal se comprendre, j'utilise les fréquences uniquement pour les blocs. Les positions relatives sont basées uniquement sur les alternances. Et d'après le corpus que j'ai, T O E A S N R I rompt moins d'alternance que O A E I S N R T

> Si l'on combine les stats de fréquence et l'alternance des mains. On > tombe sur une rangée de base du type: > OAEI SNRT > Ce qui me rappelle vaguement quelque chose...

Ne pas mélanger alternance de mains sur les digrammes et alternances consonne/voyelle. C'est _loin_ d'être toujours le cas.

>> Autre détail, d'après les statistiques que j'ai, on risque de se >> retrouver avec un layout assez étrange, par exemple des lettres sur >> la rangée du haut >> Enfin là encore, c'est tiré des stats, et que donc y'a d'autres >> symboles plus fréquents qui seront ailleurs. > > Il ne faut pas faire une fixation sur les stats non-plus. Ou alors, il > faut aller jusqu'au bout. > Quel est, statistiquement, le gain ou la perte d'efficacité d'un > clavier lors de la permutation de deux touches à faible fréquence? > Au pif, je dirais qu'il est de l'ordre du centième de pour-cent et > donc parfaitement négligeable.

En fait je voulais dire par là que ce qu'on trouvera dans la rangée du haut, ce n’est pas forcement la même chose que sur un azerty. Je sais très bien qu'il faut garder un minimum de cohérence. D'ou certaines contraintes :

tous les chiffres accessibles de la même façon (pas 3 en directe et 7 en shift

...)

toutes les majuscules des 26 lettres sur la même touche que les lettres

minuscules

après statistiques il apparait qu'on aura probablement la même chose pour < et

> (de la même façon que l'azerty pc105)

pas n'importe quoi placé n'importe comment dans la mesure du possible, par

exemple pas de lettre (non accentuée) dans la rangée du haut

Après pour ce qui est de la position de la ponctuation, là ca sera par calcul Calcul par ailleurs vraiment long, donc les symboles de la rangée du haut, ca sera plus ou moins à vue de nez.

D'ailleurs, serait-il possible que les personnes ayant des remarques relatives à la carte du clavier (http://gpl.insa-lyon.fr/Dvorak-Fr/CarteDuClavier) les y mettent. En effet la répartition (et particulièrement le nombre de touches par bloc) influence énormément le temps de calcul.

Nicolas

J'ai fini mon script qui génère les statistiques, il fait les statistiques en considérant deux points importants pour l instant :

les nombres d'occurrences d'un symbole en minuscule et majuscule sont cumulés

Les lettres (minuscules) accentuées qui ne sont pas dans les n premiers

symboles (n = 48 pour les claviers pc105) sont découpés en accent mort + lettres.

Le problème le plus embêtant, c'est qu'on aura beaucoup de mal à respecter toutes les contraintes suivantes :

shift + lettre accentuée en accès direct donne la lettre accentua en majuscule
on essaye de ne pas trop éloigner les symboles appairés
on respecte les statistiques pour les ponctuations

Suite aux discussions sur les majuscules et leurs accents, il apparait qu'il faut mapper 4 symboles (? ? ? ?) en accès via la touche shift. Cela occupe donc 4 touches. Si, pour des raisons ergonomiques, on limite l'utilisation de la touche altgr à la partie gauche du clavier, on peut donc affecter 142 symboles sur le clavier : 48 en direct 48 sur shift 23 sur altgr 23 sur altgr + shift

La question qui se pose : quels symboles doit on mettre ? Ceux présents dans les corpus ? Tous ? Seulement eux ? Ceux du charset ISO-8859-1 ? Tous ? Seulement eux ? Ceux du charset ISO-8859-15 ? Tous ? Seulement eux ? Pour info, l'ISO-8859-15 comporte 256 symboles. Si on enlève les 64 symboles qui ne sont pas affichables (séries 0x 1x 8x 9x), les 2 espaces (normal et insécable), et DEL (7F), on descend à 189. Il y a 29 lettres accentuées donc seulement 4 en accès direct, donc on gagne 2*25 symboles mais on perd 7 touches d'accents mort, on descend à 146. On peut gagner encore un peut en utilisant les compositions qui sont dans la locale normalement :

 dead-^ + 1 = ?
 dead-^ + 2 = ?
 dead-^ + 3 = ?

On descend donc à 143. Il manque encore une place, donc on pourrait se séparer d'un symbole rare (le troisième ne l est pas tant que ca) :

soft hyphen (AD)
macron (AF)
circum (5E) qui pourra toujours être atteint par dead-circum suivi d'espace ou

autre On peut donc éventuellement caser tous les symboles latin9. Quelques références : http://en.wikipedia.org/wiki/ISO_8859-15 et http://www.columbia.edu/kermit/latin9.html

<utopie> Faire un programme simple qui calcule rapidement et de façon entièrement autonome le layout en fonction d'un corpus </utopie>

> Qu'est ce qui vous choque dans le fait qu'il y ait trop de code ?

Le code a une composition très différente du texte en français :

- beaucoup de mots-clef extrêmement fréquents (for, let, #define)
- chaque langage a son jeu de symboles propres qui est particulièrement

fréquent (", {, ', ;...)

- la nature même du texte (chaînes de caractères, noms de variables...) est

différente (souvent de l'anglais, racines fréquemment répétées dans les noms de variables...) Tout cela a un impact significatif sur le corpus, en particulier si on a 7% de code dans le corpus. Imagine, 7% de texte avec un { toutes les 5 lignes, et des lignes de 15 caractères en moyenne... il y en aura plus que des W, au final. En fait, avoir du code dans son corpus doit selon moi avoir un impact uniquement sur le placement relatif des caractères les moins utilisés dans un texte en français "normal" (littéraire). En plus, le choix du langage est primordial. Si on fait du C, on aura { et } sur les touches de base; si on fait du lisp, ce sera [ et ]; du Perl? #, &, ^, /, *, $ et %... Ce que j'ai essayé de faire dans mon corpus était de mettre des échantillons d'un grand nombre de langages de programmation. En fait, il faudrait aussi que j'en supprime tous les symboles alphanumériques et de ponctuation fréquents (.,';:) Au final, il faut un corpus suffisant représentant divers langages de programmation, mais il faut absolument éviter qu'ils ne modifient les symboles fréquents des textes littéraires (qu'on tape tous aussi beaucoup, soit dit en passant).

Bon alors je propose la méthode suivante, en espérant que ce ne soit pas trop indigeste Créer un corpus standard (par exemple textes d'auteur, mail, page web), et on génère les statistiques comme précédemment avec ce corpus. A coté on génère une série de corpus spécialisés (par exemple un pour le code, un pour saisie de tableau numérique...). De ces corpus spécialisés on génère aussi les statistiques sauf que :

pour les monogrammes : on ne fait pas de statistiques sur les symboles courant

du corpus standard (donc ni lettre, ni ponctuation, ni chiffre (pour le corpus de code)).

pour les di/tri grammes : on fait les stats normales mais on vire les di/tri

grammes contenant uniquement des symboles courant (ceux éliminés ci dessus). Ainsi, les statistiques de ces corpus n'influenceront pas les placements des symboles courant qui seront placés avant. Enfin on génère un layout par la même méthode qu'avant. On aura donc un layout dont la partie code et autres du corpus n'influenceront pas les symboles classiques (lettres, ponctuation...). Pour les proportions de code de mon corpus, je les avais données dans un ancien mail mais en gros c'était surtout C++/Perl/PHP (d'ou le placement des { }).

>Est-ce que tu peux présenter la méthode que tu as utilisée pour élaborer ce clavier? >Désolé si elle a déjà été postée sur la liste (j'ai du la rater...) ou >sur le wiki (il est inaccessible pour l'instant). Elle est sur le wiki mais en voici un résumé : Pour les statistiques :

Création du corpus
Génération de statistiques des symboles
Remplacement des lettres accentuées non accessibles directement par accent

mort + lettre

Calcul des digrammes et trigrammes

Pour le calcul en lui même : Pour chaque catégorie de touche définie sur la carte du clavier sur le wiki. Je prends autant de symbole que de touches. Je teste toutes les combinaisons et pour chaque je calcule le cout du aux alternances des séquences entre les symboles en cours de placement et ceux déjà placés. Je retiens la combinaison du cout le plus faible. Je réitère avec la catégorie suivante en tenant compte des touches placées précédemment. Inconvénient : seuls les trigrammes font tenir compte des lettres qui ne sont pas encore placées

Globalement la méthode :

répartir les symboles sur les touches par fréquence des symboles et facilité

d'accès des touches

alternance des mains
frappe orientée vers l'intérieur du clavier

Ceci sur un nombre réduit de symboles, le but étant de n’utiliser les autres corpus que pour placer les caractères spécifiques dont les occurrences dans les corpus normaux n'influenceront pas le positionnement.

Les 13 caractères qui manquent sur la rangée supérieure sont : - ? " ) ( ? ? ? * _ = @ + C'est en voulant les placer (à la main, comme l'?, contrairement aux 34 autres touches) que je me suis rendu compte de la présence du ". Les placements restant (ces 13 symboles, ainsi que les altgr et altgr+shift) seront fait à la main, donc de façon subjective... Il y a 5 voyelles accentuées accessibles directement, ? et ? étant fréquentes en début de mot j'ai considéré que ce sont celles qui ont le plus de chance de se trouver en capitales. C'est pourquoi je n'ai pas forcé le fait que ? et ? soit en partie centrale. Le ? quant à lui est en partie centrale, non pas à cause de l'emploi fréquent en capitale, mais à cause de son emploi fréquent tout court. Contrairement à la proposition que j’avais faite avant les vacances, je n'ai pas utilisé de corpus orienté code, les symboles { } et autre # et \ ne sont donc pas accessible directement, mais le seront par altgr (partie gauche toujours). Un autre point toujours par rapport à ma proposition précédente, cette fois aucune touche n'a été forcée dans une zone particulière (typiquement l'emplacement de la ponctuation l'avait été, ce n'est pas le cas pour cette fois, le fait qu'il y ait 4 touches ponctuation/accent contiguës est pure coïncidence). Le seul symbole dont j'ai forcé l'emplacement est l'œ (l’e-dans-o, et non pas 1/2). J'ai fait ce choix par rapport à la suggestion de Fabien JOBIN qui était de se mettre dans le pire des cas, la première étape à mon avis étant de se passer de touche <> (qui n'existe pas non plus sur les claviers qwerty Sun (d'après Bruno Ducrot, mail du 10 mars 2004) ou tout pc104)

Pour ce qui est de l'algorithme, c'est toujours un placement par bloc. A la différence de l'ancienne proposition, j'ai cherché à faire converger les répartitions, c'est à dire qu'une fois un bloc placé, on fait le suivant, mais quand c'est fait, on recalcule le premier car l'algorithme considère les touches non placées comme idéalement placées. C'est évidement pas le cas donc j'affine le résultat à mesure jusqu'à convergence qui s'est finalement produite, c'est-à-dire que quelque soit le bloc que l'on veut recalculer, on retombera sur ce résultat (je n’ai pas testé un calcul de morceaux de bloc distincts). Voila, en espérant que cette proposition choque moins que la précédente :)

Il faudrait demander à des français, belges, suisses, et québécois notamment quels caractères de leur clavier respectif leur semblent indispensable d'être repris, et pourquoi (par exemple compatibilité avec le flamand, l'anglais, l'allemand, l'italien ou l'espagnol).

Le regroupement des voyelles à gauche est (au moins pour ma version dvorak-fr) tout sauf une convention, c'est simplement le résultat de la minimisation des critères qui ont été établis comme étant handicapant au niveau confort que vitesse. Pour rappel, on essaye d'avoir : - meilleure alternance gauche/droite ; - meilleure répartition gauche/droite du pourcentage des fréquences d'apparition des caractères ; - en cas de digramme sur la même main, le diriger vers l'intérieur de clavier ; - de préférence les symboles sur la rangée centrale, puis supérieure, puis inférieure, puis celle des chiffres (et l'adapter légèrement aux défauts des claviers courants pas adaptés aux longueurs différentes des doigts...). (ordre des critères indifférent)

Pour les chiffres, sur le DSK (dvorak simplified keyboard) l'ordre est le même que sur le qwerty, mais sur le dvorak d'origine non. S'il a décidé de garder l'ordre du qwerty ça ne doit pas être par hasard. Compte tenu de la fréquence des nombres tapés comparée à celle de texte, on peut laisser tel quel.

Pas from scratch, ton travail sur le placement des 26 lettres de l'alphabet est très bon (autant que je puisse en juger de ma petite opinion). Par contre au niveau des caractères spéciaux, je pense qu'il y a moyen d'optimiser -- mais je me demande encore comment procéder. Je ne sais pas si la méthode utilisée pour les lettres de l'alphabet est adaptable pour les caractères spéciaux, car elle dépend beaucoup de la nature du corpus et lui-même dépend des langages de programmations / shell qui vont être sélectionnés... En fait j'ai fait une version papier (mal aux doigts oblige) de mon projet de keymap, qui n'a plus bougé depuis quelques jours. Il faut que je la revoie rapidement, vous la montre et commence à l'utiliser.

Texte en vrac de l'ancier wiki pour rédiger l'article

Discussions