> Ich würde gerne mal wieder schauen, ob ich nicht einen ein-tag-korpus 
> erstellen kann. Mit dem Prog von Klausler kann ich zumindest mein 
> Programmieren mit emacs einfangen. 

Du meist mit einer Art keylogger?  Mit der XRecord-Extension kann man
einen schreiben, der jedes Tastenevent (leider auch solche, die durch
autorepeat erzeugt werden) mitbekommt, nicht nur solche in Emacs.
Leider müsste man mühsam die aktuelle Ebene und daraus die eingegeben
Zeichen rekonstruieren, der Modifikatorstatus wird nämlich nicht
mitgeliefert.  Bei Bedarf kann ich mich näher dazu auslassen.

Wenn du an einem Tag soviel tippst, dass das Ergebnis statistisch
brauchbar ist, bist du wirklich schnell.  Und wenn es darin nicht vor
Tippfehlern wimmelt bist du sehr sorgfältig.  Und wenn das Ganze dann
noch irgendwie repräsentativ ist, bist du sehr durchschnittlich, und das
passt nicht zu «sehr schnell» und «sehr sorgfältig».

> > Ich bin von meiner Ansicht abgerückt.  Heute behaupte ich, man müsste
> > die u-ShiftL-Kollision normal und die von u-b Kollision schwächer
> > werten, weil zwischen u und b ja noch eine Taste (ShiftL) gedrückt wird.
> > Das ist ein Spezialfall einer «indirekten Kollision»: Einer Kollision
> > zwischen Tasten, zwischen denen eine weitere Taste mit der anderen Hand
> > oder mit dem Daumen getippt wird.  Mein aktuelles Lieblingsthema.
> 
> Könntest du mir das erklären? Am besten direkt auf der Liste :)

Es geht um Sequenzen von drei Tasten, von denen die erste und die letzte
auf derselben Hand liegen, die mittlere aber nicht.  Solche Sequenzen
mit zwei Handwechseln sind schnell zu tippen.  Daher kann man sich
vorstellen, dass die Position der ersten Taste einen Einfluss darauf
hat, wie leicht oder schnell die dritte zu tippen ist.

Die einfachste Art, das in eine Bewertung einfliessen zu lassen, ist dem
Trigramm dieselbe Bewertung zu geben wie dem Bigramm aus erstem und
letzten Zeichen, multipliziert mit einem Faktor kleiner eins.  Der
Faktor könnte vom Tippaufwand der mittleren Taste abhängen: Je besser
oder schneller die mittlere Taste getippt werden kann, desto grösser der
Faktor.  Das ist aber vermutlich nur eine unnötige Komplikation.

Sequenzen wie bei der Eingabe von «uB», wenn u und b auf der selben Hand
sind, sind ein Spezialfall davon, wobei Shift die mittlere Taste im
Tasten-Trigramm ist.  «Bu» ist ähnlich, aber nicht ganz gleich: Die
erste Taste ist Shift und die mittlere b.  Allerdings muss Shift
gehalten werden bis b gedrückt ist, daher beeinflusst Shift das u
stärker als die erste die dritte Taste in normalen Trigrammen.  Der
Vorfaktor vor dem Bigrammgewicht sollte daher grösser sein, aber nach
wie vor kleiner eins.

Bei Trigrammen ohne Handwechsel kann die erste Taste natürlich auch
bestimmen, wie gut die dritte zu tippen ist.  Die Situation ist aber
viel verwickelter, da die mittlere Taste eine grosse Rolle spielt.

Wenn man Trigramme mit zwei Handwechseln auf die beschriebene Art in die
Bewertung einbaut, kann unter Umständen (das hängt von anderen den
Details des Bewertungsschemas ab) etwas Interessantes passieren: Die
Vokale bei der optimalen Tastatur verteilen sich auf beide Seiten und
man hat nur noch «wenige» Handwechsel (vielleicht bei 55% aller
Bigramme).  In dieser Hinsicht ähneln diese Belegungen stärker modernen
Belegungen wie Colemak und Arensito als Dvorak.

> Ich habe allerdings noch kein effizientes System im Kopf, um das sauber zu 
> machen. Wie hast du das implementiert? 

Das kannst du im Optimierer sehen, in den Funktionen «aufwand» und
«diff_aufwand», siehe http://wettstae.home.solnet.ch/opt.c (Falls jemand
damit rumspielen will, ich habe das auch zusammen im Paket mit meinen
Korpora, in http://wettstae.home.solnet.ch/Optimierer.tar.gz).

> Die Kosten von Tasten (nicht Zeichen) kann ich ja eigentlich zwischencachen 
> (die bleiben bei dem Layout ja gleich). Mappst du dann einfach die 
> Tastenpositionen und Kosten auf eine Matrix und schreibst die Bigramme in 
> Positionen um? 

Genau.  Jede Taste hat einen Index zwischen 0 und ntaste-1, und zwei
solcher Indices geben bezeichnen einen Eintrag in der Matrix mit vorab
berechneten Bigrammkosten (Dazu kommen noch zusätzliche Indices für die
Behandlung von Shift, aber das ändert nichts am Prinzip).

Mit den Bigrammhäufigkeiten ist es genauso, nur sind die Indices nicht
Tastennummern, sondern Buchstabennummern, auch sie von 0 bis ntaste-1
nummeriert.

Kosten und Häufigkeit finden durch die Belegung, dargestellt durch eine
Permutation p der Zahlen 0…ntaste-1, zueinander.  Die Bigrammbewertung
ist dann eine Summe von K(i,j)*H(p(i),p(j)) über alle i,j.  Ein- und
Trigramme sind analog.

Andreas

Antwort per Email an