robin_moussu
@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#Utilisation_recommand.C3.A9e
lawrent
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 écritlawrent a écritEn 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 écritUn 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 écritlawrent a écritEt 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
lawrent a écritLaurent, ç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 écritLaurent dans un autre post a écritlawrent a écritEt 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
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
yeKcim
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 ?
Mimoza
"{}" dans la même position que "<>"
le ";" m'est plus utile que la ","
Bref pour taper du code c'est pas pratique
yeKcim
question dont je ne trouve pas la réponse : pour le groupe de texte permettant de définir les touches les plus fréquente, est-ce que la méthode est de prendre des textes dans pleins de langue et d’appliquer des coefs ou c’est une autre méthode qui est appliquée ? avec cette méthode le ç s’éloigne surement au profit du w par exemple…
yeKcim
Autre souci : je n’utilise jamais ' mais toujours ’ mais c’est sûrement parce que je ne dev pas beaucoup. Peut-être faudrait-il faire un topic pour lister… ou un système de vote pour indiquer d’une façon ou d’une autre combien de personnes trouve chaque point gênant…
ariasuni
J’avais commencé à lister les défauts et c’est devenu ça:
http://bepo.fr/wiki/Utilisateur:Sinma/V2/Symboles
Pour les défauts, j’ai commencé un sujet ici:
http://forum.bepo.fr/viewtopic.php?pid=9135#p9135
Laurent
yeKcim a écrit→ < et > impossibles à une main donc faiblement accessibles
En quoi est-ce utile qu’ils soient faisables à une main ?
Pour ma part, je les ai
mis en AltGr mais sous la position de repos (je peux même faire un roulement pour <=, >= voire pour <>, <=>, spécifiques à Perl) : je préfère conserver les caractères utilisés pour le français au maximum en accès direct pour ne pas freiner ma frappe, alors que pour les signes fréquents dans les langages informatiques, j’ai cherché en priorité à ce qu’ils soient bien placés pour améliorer le confort. Les langages informatiques nécessitent une précision qui demande de toute façon plus d’attention et donc moins de vitesse.
yeKcim
pour coder en html c’est huper pénible en comparaison d’un azerty
dans inkscape le raccourcis clavier ctrl+< et ctrl+> est chiant à faire
là comme ça je ne vois pas d’autres remarque
lawrent
Pour en finir une bonne fois pour toutes avec les trigrammes.
Si on veut faire comme pour le MTGAP, ce dont il a besoin, c'est:
- un corpus représentatif sur lequel évaluer la disposition
- une carte d'accessibilité
- une carte d'accessibilité pour les digrammes
- une carte d'accessibilité pour les trigrammes
la fonction d'évaluation alors, elle passe le corpus à travers la moulinette et elle compte les points en fonction des cartes d'accessibilité et à la fin elle divise par le nombre de caractères corpus pour avoir une valeur normalisée.
(et pour ceux qui n'ont pas lu la page du MTGAP, son algo évolutionnaire il consiste à chaque génération à prendre toutes les dispos de la précédentes, faire un swap aléatoire entre 2 touches sur chaque dispo et exclure la moitié des dispositions qui score le plus haut.)
ce qui nous fait 4 paramètres sur lesquels on peut jouer:
- un fichier txt externe
- un tableau à 35 entrées (si on se limite à la région centrale)
- un tableau à 35² entrées
- un tableau à 35³ entrées
où on doit encoder nous-mêmes les valeurs de ces 3 tableaux parce que c'est eux qui définissent les critères que satisfera la dispo finale. Pour la carte d'accessibilté on peut encore se permettre d'encoder toutes les valeurs à la main, pour les digrammes et les trigrammes si on veut pas devenir dingue je proposerais qu'on se limite à une échelle à 3 ou 5 valeurs: (très bon), bon, neutre, mauvais, (très mauvais). Il faudra faire des essais pour voir à quelle pénalité exactement ça correspondra.
Une fois qu'on a ça on n'a plus besoin de se préoccuper avec des règles subjectives comme "les roulements vers l'intérieur ça fait +1, les roulements vers l'extérieur ils sont pas bons, les trigrammes sur 2 lignes on les aime pas" qui s'écriraient comme un interminable if-then-else.
Note qu'on pourrait très bien écrire un petit programme qui écrirait les cartes d'accessibilité pour nous, parce qu'il y aura forcément des patterns communs à plusieurs di/trigrammes: par exemple, tous les digrammes qui incluent la même main et un saut de ligne, on les aime pas—sauf exceptions. Et il y aura beaucoup de di/trigrammes neutres dans la liste…
robin_moussu
> Une fois qu'on a ça on n'a plus besoin de se préoccuper avec des règles subjectives comme "les roulements vers l'intérieur ça fait +1, les roulements vers l'extérieur ils sont pas bons, les trigrammes sur 2 lignes on les aime pas" qui s'écriraient comme un interminable if-then-else.
Si on fait des trigrammes (ce que j'aimerais), il est impossible (faute de temps humain) de tous les écrire. Il faut donc les générer, et du coup pour les générer il faut avoir cette liste subjective.
robin_moussu
j'ai créé un framapad
http://lite4.framapad.org/p/4kP4f5nj8z suite à la discussion sur ce thread
http://forum.bepo.fr/viewtopic.php?id=1020. Je n'ai pas de temps de fouiller ce thread pour voir si il y a des trucs à rajouter en provenance de celui-ci. Si une bonne à le temps de la faire c'est cool.
lawrent
Quelques idées pour la partie algorithmique:
- Convertir le corpus en une longue chaine de chiffres (0 est un chiffre représentant les frappes non-incluses dans la liste des caractères à placer: \n, \t, ï, û, …, etc.).
- représenter une disposition comme une permutation D dans S_35 (ou S_x avec x le nombre de touches sur le clavier à décider).
- évaluation d'une disposition = Eval(D(corpus)). En d'autres mots:
-- D est une fonction : Corpus in {0,35}^L -> Séquence de touches in {0,35}^L
-- Eval est une fonction qui calcule la pénalité associée à une séquence de touches
tout ça sera codé en C, pour des raisons de vitesse de calcul (évaluer le corpus risque d'être très long…)
--- OU ALORS ---
étant donné que la fonction d'éval ne fait que compter le nombre de 1-grammes, 2-grammes et 3-grammes dans le corpus traduit, on peut résumer le corpus en 3 tables:
- tab1[x] : vecteur qui compte combien de fois la lettre x apparait dans le texte
- tab2[x][y] : matrice qui compte combien de fois le digramme xy apparait dans le texte
- tab3[x][y][z] : tenseur qui compte combien de fois le trigramme xyz apparait dans le texte
et les occurrences sont divisées par le nombre de caractères, histoire de normaliser tout ça
auxquels correspondent 3 tables de paramètres:
- coeff1[x] : la pénalité associée à la touche x
- coeff2[x][y] : la pénalité associée à la succession de touches xy
- coeff3[x][y][z] : il faut vraiment que je l'écrive?
La fonction de cout devient alors rapide à évaluer:
COUT = SUM_i D(tab1) * coeff
+ SUM_ij D(tab2[j]) * coeff2[j]
+ SUM_ijk …
ce qui doit fait quelque chose de l'ordre de 100,000-200,000 flops
robin_moussu
@lawrant : ce que tu dis est pertinant mais je ne peux m'empécher de relever « tout ça sera codé en C »
Alors là pas question. Je sais faire du C, mais c'est un langage à peine mieux que l'assembleur 🙂 Si on veux des perfs, on prend du c++, et en plus on a (ceux qui veulent coder) des connaissances en c++.
Le prend pas mal, mais je suis trop fatigué pour ne pas mordre au troll !
lawrent
Robin: je le prends pas mal 😉 à la base j'avais écrit toutes ces notes d'un seul jet pour moi-même. Le "ou alors" a marqué le moment où j'ai changé d'avis et j'ai pas eu la motivation de réécrire proprement mes notes avant de les poster sur le forum. En pratique vu que la fonction d'évaluation sera relativement légère j'écrirai probablement tout ça en Matlab, langage que je maitrise mieux. Après ça reste mes choix personnels de bidouilleur qui veut faire ça dans son coin.
damien thiriet
Je signale juste un point de statistique concernant la taille du corpus: à partir du moment où l’on atteint 1000 unités, un échantillon aléatoire ne donne une marge d’erreur que d’1% par rapport à toute la population. C’est pour ça que les sondages utilisent cet échatillon.
Pour les faibles taux, il faut un échantillon plus large, mais pas besoin d’un corpus gigantesque alourdissant le calcul, 1Mo suffirait largement… Ce qui ne résoud certes pas la question de sa composition.
Arathor
Pas le temps de tout lire, mais par rapport au dernier message : une marge d’erreur de 1%, ça passe pour les sondages politiques mais c’est inadmissible dans notre cas. Cf tous les caractères qui gravitent entre 1 et 2 %, voir moins de 1 %.
La conception et les calculs prendront le temps qu’ils prendront, on est là pour faire les choses correctement.
damien thiriet
Je suis d’accord, mais avec un corpus de quelques megas, on a largement suffisamment pour que les marges d’erreur des caractères à faible occurence soient réduites au maximum. 1% d’erreur, c’est un corpus de 1 à 4 ko (en prenant l’hypothèse qu’une lettre = 1, 2 ou 3 octets. Les cas à 4 octets doivent être rares, non?). Donc quelques mégas sont largement suffisants à mon sens.