A2 : Nouvelle page : ==Texte en vrac de l'ancier wiki pour rédiger l'article== Le ¡ c'est pas un caractère francophone, s'il est sur le clavier, il sera là où on peut, mais on se casse pa...

2007-10-09T17:00:03Z

Nouvelle page : ==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 pa...

Nouvelle page

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

==Discussions==

Discussion:Méthodologie - Historique des versions

A2 : Nouvelle page : ==Texte en vrac de l'ancier wiki pour rédiger l'article== Le ¡ c'est pas un caractère francophone, s'il est sur le clavier, il sera là où on peut, mais on se casse pa...

A2 : Nouvelle page : ==Texte en vrac de l'ancier wiki pour rédiger l'article== Le ¡ c'est pas un caractère francophone, s'il est sur le clavier, il sera là où on peut, mais on se casse pa...