Version du 10 novembre 2012 à 17:22

Robipo Pour s’y retrouver et éviter d’avoir des discussions qui partent dans tous les sens, je propose le plan suivant qui correspond à un plan temporel (ouvert aux critiques)

Corpus et Clavier (pour Bépo corpus = Thomas Tempé, et clavier = standard décalé français (TODO : quelle Méthode de saisie a été utilisée ? std,t6,o0,A))
Algorithme (pour Bépo voir http://www.bepo.fr/wiki/Cr%C3%A9ation_de_la_version_0.1)
Ajustements (pour Bépo voir les logs de la ML ?)

Corpus et Clavier

Corpus

Corpus "informatique" (principaux languages de prog, shell unix, etc)

Ce point me gène. Les langages apparaissent, évoluent et meurent. Voir « figer » une disposition sur du mouvant me parait impossible. Enfin, si. Mais faut re-figer tous les 6 mois. *_Si_* j’ai raison (prions que je me trompe), ça va vite vous faire chier.

J’espère cette fois avoir su m’exprimer clairement.

Fork Bomb 19 octobre 2012 à 13:31 (UTC)

D'une part les choses bougent sur une période de temps bien plus longue que 6 mois. L'index TIOBE (qui vaut ce qu'il vaut, mais qui a le mérite d'exister) donne dans le top 10 : C, Java, Objective-C, C++, C#, PHP, (Visual) Basic, Python, Perl, Ruby. Mis à part C#, tous ces languages ont au moins 15 ans (et C# en a 10), voir beaucoup plus.

D'autre part, les languages populaires ont tendance à réutiliser des caractères similaires : {} pour les blocs, [] pour les tableaux, ; pour les fins de lignes, etc.

Enfin, il faut bien bouger et faire quelque chose, quitte à mettre à jour la dispo dans 10 ou 15 ans. Une disposition rationnelle des caractères spéciaux, basée sur la technique actuelle, sera toujours mieux que celle au petit bonheur la chance de la V1 (sans AltGr symétrique, qui plus est).

Arathor 20 octobre 2012 à 03:29 (UTC)

En effet, si on regarde bien, on a les paires (), [], <>, {}, /\, les signes mathématiques +-*/=, logiques &|!, et les autres :,~^"'`$#*%@;. Ça fait beaucoup de signes mais ce sont toujours les mêmes !

Sinma 20 novembre 2012

Langues étrangères

Dans la section « Déterminer l’ordre des priorités » on distingue les langues de l’UE des autres langues étrangères, principalement parce que les utilisateurs occidentaux ont plus de chance d’écrire dans une de ces langues. Mais une bonne partie des francophones vivent en Afrique et sont souvent polyglottes. Je pense que de la même façon que les langues européennes ont un « statut » spécial, les langues parlées dans les zones francophones devraient aussi bénéficier de ce « statut ». J’ai commencé à lister ces langues et les lettres associées sur la page User:LeBret/Bépo_dans_le_monde.

J’ai conscience que cela ajoute beaucoup de lettres (cela repose la question des variantes). Mais cela me semble important d’autant que ces langues sont rarement bien supportées par l’informatique.

LeBret 29 octobre 2012 à 20:28 (UTC)

L'idée n'est pas mauvaise, mais ton tableau il fait peur… même en rajoutant une touche morte en altgr de chaque touche, ça rentrerait probablement pas… Arathor 31 octobre 2012 à 20:57 (UTC)

La solution pourrait être d’ajouter, en plus des deux touches d’accès au 3me niveau (Alt Gr), deux touches d’accès au 5me niveau. Ça ferait un total de 8 niveaux, ce qui doublerait presque l’espace disponible. Si l’on y ajoute une touche Compose facilement accessible, il n’y a plus de limites, si ce n’est l’impossibilité d’implémenter ladite touche Compose dans PKL (le pilote portable pour Windows) sans en modifier le code. Tohuvabohuo 7 novembre 2012 à 23:58 (UTC)

Clavier

Robipo : Je vote pour faire une version standard avec utilisation de pondération, et de laisser la possibilité aux utilisateurs avancés de se génerer leur propre disposition à leur risques et périls, mais pour avoir une disposition totalement optimisée.

Sinma : Comme maintenant quoi… Je pense que c'est une bonne idée mais à condition d'encourager un max les retours utilisateurs, pour essayer de ne pas avoir de retour négatif (certains doigts trop chargés, position du Z et du W, symboles de programmation…) C'est à dire une bonne partie de ce qui a engendré les dispositions dérivées du bépo.

Robipo : Non, pas comme maintenant, le bépo actuel est fait uniquement en fonction des claviers standard décalés. Pas de pondération.

Sinma : milles excuses, j'avais oublié ce point.

Je pense qu'il y a deux choses distinctes ici : le ou les types de clavier visés d'une part, et d'autre part l'utilisation (taper du français uniquement ; mélange français/anglais ; informaticien ou non). Pour plusieurs raisons différentes, il vaut mieux une seule version officielle et éventuellement d'autres versions à côté.
http://bepo.fr/wiki/V2#Variantes_ou_pas
Pour les types de claviers supportés, je pense que la cible de base reste les claviers pc10X (ce qui inclue les 102, 103, 104) mais qu'il faut aussi prendre en compte les claviers ergos. Je suis pas certain que la méthode de Robipo (0.8 std + 0.1 typematrix + 0.1 TE) donne un résultat intéressant, mais je me trompe peut-être. À mon sens une manière efficace de prendre en compte les claviers ergos (notamment les symétriques, +1 avec XavierC) c'est avec des contraintes du style « pas de lettres sur le pavé auxiliaire ». Arathor 9 novembre 2012 à 14:23 (UTC)

le type de clavier est discuté ici, l'utilisation est prise en compte par le corpus (cf partie précédente) : merci d’en parler là-bas (en l’occurrence, je pense que pour le corpus/utilisation une méthode similaire serait également le mieux (à savoir pondérations par ex 0.8fr 0.1en 0.1divers pour une version officielle et possibilité de faire des versions custom)). Je pense que pondérer les claviers ergos ou utiliser des contraintes du style pavé auxilière auront un résultat similaire niveau stats finales (bien que l’utilisation de pondérations risque aussi de donner des modifications plus fines, par exemple l’accessibilité de certaines touches changeraient suivant que ce soit un clavier ergo ou clavier décalé, ce qui serait difficile à décrire via des contraintes, sans passer par les pondérations sus-citées). Robipo 9 novembre 2012 à 20:40 (UTC)

Claviers standards

Comme le bépo.

Avantage : C’est la dispo utilisée par la majorité des claviers, et donc les claviers pas chers de monsieur tout le monde
Inconvénient : En général les personnes intéressé par l’ergonomie et le bépo seront aussi intéressées par les claviers ergo, donc ce serait dommage de les handicaper (comme le bépo par défaut qui devient horrible sur le TE)

Pondérer les claviers dans l’algo (par ex : 0.8std + 0.1tmx + 0.1te)

Avantage : Adaptée à tout type de clavier, il ne devrait pas y avoir de clavier sur lequel la disposition est affreuse à utiliser.
Inconvénient : La dispo n’est parfaitement optimisée sur aucun clavier réel, c’est une sorte de disposition optimisée pour un clavier abstrait.

Sinma : Le Truly Ergonomic ne me parait pas autant utilisé que le TypeMatrix…

Robipo : Exact, c’est juste un exemple, il est évident que la pondération finale sera sujette à de plus vastes discussions.

Ne pas suivre la mode et les tendances car si cela se trouve d'ici 5 ans le clavier ergo le plus utilisé ne sera aucun des deux cités et on se retrouvera avec les mêmes problèmes. L'idéal serait de faire une dispo par clavier mais ce ne serait pas pratique : il faudrait au moins tenir compte des grandes familles de clavier et veiller particulièrement aux prometteuses dispositions symétriques (TECK, Maltron, μTron…) qui semblent avoir le design le plus intéressant ergonomiquement. XavierC 9 novembre 2012 à 04:52 (UTC)

Sinma : Ou alors simplement faire une pondération entre claviers standards et claviers à rangées orthogonale ? (c'est à dire : essayer de prendre en compte les caractéristiques d'un clavier ergonomique sans ce limiter à ceux qui existent déjà actuellement)

même si les claviers ergos actuels n’existent plus dans le futur, les bases resteront les mêmes (pavé auxilière, ortho), donc les stats seront assez semblables. Si les claviers ergos du futur changent vraiment beaucoup, alors ses précurseurs pourront génerer leur disposition perso, et si ils deviennent plus utilisés alors il faudra songer à une éventuelle v3. Mais franchement, ne pas pondérer les claviers ergos actuels parce qu'ils ne seront peut-être plus dans le futur, ce serait un peu comme essayer de prévoir le futur, ou genre intégrer dans le corpus des langages de programmations très récents dont on ne sait pas si ils vont avoir un succès ou pas. Robipo

Sinma : Ce que je veux dire c'est de prendre en compte les caractéristiques génériques d'un clavier ergonomique pourrait être un bonne idée. Mais je peux me tromper.

Faire une dispo par type de clavier

Avantage : La dispo sera parfaitement optimisée (on peut imaginer que l’algo mette la touche E sur un des espaces du TE par exemple)
Inconvénient : Faudra faire les ajustements pour chaque clavier, et pour la standardisation et la reconnaissance, c’est pas génial.

Rien n'empêche de faire une seule version officielle et de proposer en option, pour les passionnés, une version pour chaque clavier (et les outils pour personnaliser encore plus si c'est ce que veut l'utilisateur). Arathor 9 novembre 2012 à 14:23 (UTC)

Oui, c’est exactement ce pour quoi j’ai voté en introduction. Robipo 9 novembre 2012 à 20:40 (UTC)

Algorithme

Robipo : Je pense qu’utiliser un algorithme génétique est le mieux

Croisement très facile à faire : pour chaque touche des deux dispositions parentes, on prend aléatoirement celle du père ou celle de la mère.

Pas si facile que ça en fait. Il se peut que tu mettes 2 fois une lettre en la prenant quelque part du père et quelque part de la mère. Et que tu en supprimes aussi… Amic 10 novembre 2012 à 16:22 (UTC)

Mutation assez facile : on inverse deux caractères aléatoire par exemple aAæÆ oOœŒ donne ŒAæÆ oOœa (bon ok ce cas est complètement stupide et pour améliorer la rapidité de l’algorithme il faudrait rajouter des contraintes)

Robipo : Idée au passage avant que j’oublie : Quand on laisse tourner l’algo qui optimise les coûts, ce serait bien de voir quelques-unes des meilleures dispo de l’algo en temps réel. Au lieu de s’emmerder à faire une interface graphique, ce serait pas bête de faire que l’algo exporte en continu dans un fichier .html les dispos. Ensuite il suffirait de faire un petit javascript qui refresh en boucle l’affichage de ces dispo. (avec un peu de css on peut avoir un rendu assez sympa je pense).

Calcul des coûts

Avant de choisir une méthode, je pense qu’il faudrait faire des benchmark sur un assez gros corpus, et voir les différentes distances obtenues pour chaque méthode et voir si il y a beaucoup d’écart.

En utilisant un algo génétique on peut aussi imaginer procéder en deux phases : à partir de dispositions purement aléatoire, on fait un premier jet avec un algo rapide mais moins fiable pour obtenir une population « passable » de dispositions assez rapidement, puis on fait une deuxième passe avec l’algo qui parcourt tout le corpus et est bien fiable pour affiner la population. Robipo 9 novembre 2012 à 21:00 (UTC)

Utilisation des statistiques de fréquences

Avantage : très rapide
Inconvénient : calcul la distance avec les doigts qui reviennent sur la disposition de repos après chaque touche. « bobo » (ou « bébé ») compte pour 4, alors qu'en réalité il vaut 2.

Tentative d’améliorer cet algo pour trouver une sorte de compromis :

Soit les fréquences suivantes :
p 2
i 7
x 1

Principe : au lieu de donner une distance de 2 pour les touches p et x et 0 pour i, comme on sait les fréquences de chaque touche, on peut dire que quand on tape un p par exemple, il y a 20% de chances qu'on était sur un p, donc distance de 0, il y a 70% de chances qu'on était sur un i, donc distance de 1, et 10% de chances qu'on était sur un x, donc distance de 2.

quand on tape P
0.2*0
0.7*1
0.1*2
tot=0.9

quand on tape I
0.2*1
0.7*0
0.1*1
tot=0.3


quand on tape un X
0.2*2
0.7*1
0.1*0
tot=1.1


Soit le corpus suivant : iiiiiiippx (pas très représentatif)
distance réelle = 1+2=3
distance robot = 2+2+2=6
distance compromis = 0.9*2+0.3*7+1.1*1=5

Soit le corpus suivant : iiiixiipip (un peu représentatif)
distance réelle = 2+2+1=5
distance robot = 2+2+2=6
distance compromis = 5

On peut peut-être améliorer l'algo en utilisant les digrammes ? (des matheux dans la salle ?)

Parcours total du corpus

Avantage : possible de calculer la distance réelle (avec mémorisation de l’emplacement des doigts tout au long du corpus)
Inconvénient : beaucoup plus long (bépo@home BOINC serait vraiment utile dans ce cas)

Minimiser la distance parcourue des doigts

Maximiser l’alternance des mains

Exemple mauvais en bépo : épub dans république, beaucoup se tape presque uniquement à une main

Minimiser les m-grammes à n-doigts (n<m)

Digrammes à un doigt

Exemple mauvais en bépo : pi dans tapis, soupirer, épisode…

Trigrammes à un doigt

Exemple mauvais en bépo : bab dans probablement

Trigrammes à deux doigts

Exemple mauvais en bépo : ove dans novembre

Ajustements

Car on ne peut pas tout prévoir dans l’algorithme, il va falloir faire des ajustements à la disposition générée.

Ajout de variantes de lettres grecques

(ce fil de discussion a été copié à partir de Discussion:Accueil)

Au cas où des utilisateurs souhaiteraient entrer des mots isolés sans diacritique (accent, esprit…), je suggérerais d'ajouter les deux caractères suivants pour la V2:

- Le sigma minuscule final U+03C2 « ς », dont l'utilisation à la place du sigma minuscule standard U+03C3 « σ » est requise en fin de mot en grec ancien et moderne. Ce symbole pourrait être localisé sur le « C ». Pour information il est présent sur la disposition allemande Neo.

- Moins nécessaire mais intéressant: puisque ce symbole sigma final n'a pas de majuscule (il s'agirait du sigma majuscule standard) je suggérerais d'ajouter, en «majuscule» de cette même touche, le beta minuscule de milieu de mot, utile pour le grec ancien, de code U+03D0: « ϐ »

Jidé 7 novembre 2012 à 19:10 (UTC)

Pour écrire en grec, il vaudrait mieux terminer le bépo grec qui devrait aussi gérer les nombreux diacritiques.

La touche morte pour le grec n’a pas pour but de permettre d’écrire en grec, mais plutôt de permettre la saisie de lettres grecques utilisées comme symboles. Dans ce cadre, il faudrait ajouter les caractères ϑ ϒ ϕ ϖ ϰ ϱ ϴ ϵ, variantes de θ Υ φ π κ ρ Θ ε.

Tohuvabohuo 8 novembre 2012 à 03:46 (UTC)

C'est aussi ce que je pensais tout en ayant oublié l'existence du bépo grec : les ajouts du bépo ne valent pas les avantages d'une disposition dédiée sur laquelle on bascule à la volée d'une simple séquence de clavier, les lettres grecques du bépo sont plus orientées vers une utilisation en tant que symboles mathématiques saisies occasionnellement qu'en tant que saisie plus littéraire comme développée sur le Neo2 —D'ailleurs son accès aux deux couches grecques est totalement différent et pensé, lui, pour la saisie de texte.

XavierC 8 novembre 2012 à 05:05 (UTC)

@@ Ligne 66 : / Ligne 66 : @@
 [[Utilisateur:Robipo|Robipo]] : Je pense qu’utiliser un algorithme génétique est le mieux
 *Croisement très facile à faire : pour chaque touche des deux dispositions parentes, on prend aléatoirement celle du père ou celle de la mère.
+::Pas si facile que ça en fait. Il se peut que tu mettes 2 fois une lettre en la prenant quelque part du père et quelque part de la mère. Et que tu en supprimes aussi… [[Utilisateur:Amic|Amic]] 10 novembre 2012 à 16:22 (UTC)
 *Mutation assez facile : on inverse deux caractères aléatoire par exemple aAæÆ oOœŒ donne ŒAæÆ oOœa (bon ok ce cas est complètement stupide et pour améliorer la rapidité de l’algorithme il faudrait rajouter des contraintes)
 [[Utilisateur:Robipo|Robipo]] : Idée au passage avant que j’oublie : Quand on laisse tourner l’algo qui optimise les coûts, ce serait bien de voir quelques-unes des meilleures dispo de l’algo en temps réel. Au lieu de s’emmerder à faire une interface graphique, ce serait pas bête de faire que l’algo exporte en continu dans un fichier .html les dispos. Ensuite il suffirait de faire un petit javascript qui refresh en boucle l’affichage de ces dispo. (avec un peu de css on peut avoir un rendu assez sympa je pense).