Sorry, ich habe das gestern versehentlich direkt an Arne geschickt. Jetzt aber richtig:
> Für Leute, deren Job Kernelprogrammierung ist, könnte sich die Optimierung > lohnen. Auch wenn die Programmiersprache oder sogar das Programmierprojekt feststeht, man müsste noch wissen ob emacs, vi oder Eclipse benutzt wird. Was im Korpus steht ist nicht alles auch getippt worden. Tools nehmen unter Umständen einiges ab. > Genauso für Leute, die viel Griechisch oder mathematische Symbole schreiben. Die bevorzugten Symbole sind in unterschiedlichen Disziplinen verschieden. Ich glaube nicht, dass sich ein repräsentativer Korpus für mathematische Symbole finden lässt. Ausserdem, wenn man annimmt, dass die lateinischen und griechischen Buchstaben aneinander kleben (a am α und so weiter) müsste man normale Texte und Formeln gegeneinander abwiegen. > Dafür brauchen wir „nur“ einen korrekten Korpus :) > > Es geht schließlich darum, das tippen zu können, was im Korpus steht. Ja, man braucht einen hinreichend korrekten Korpus, weil nur ein korrekter Korpus repräsentiert, was man tippen will. Ich habe mir tatsächlich schon überlegt, meinen (3MB) Korpus zu bearbeiten, aber das ist viel Arbeit mit sehr begrenztem Nutzen. > Ich fände es grundlegend noch schöner, die feste Zuordnung der Finger auf die > Tasten aufzulösen. > > Zum Beispiel hat mir eine Bekannte erzählt, dass sie im Tippkurs gelernt hat, > dass bei Neo „sh“ das „s“ vom Zeigefinger und das „h“ vom Mittelfinger > gedrückt > werden sollte. Das läuft darauf hinaus, dass derselbe Text bei derselben Belegung mit unterschiedlichen Bewegungen getippt werden kann. Schwierig zu bewerten und schwierig zu lernen. Es könnte aber wirklich die Tippeffizienz steigern. Gerade auf der linken Tastaturhälfte könnte man einiges mit den «falschen» Fingern machen. > > Das ist das Bigrammgewicht Mod6R-Mod6L. Hier müsste man allerdings noch > > berücksichtigen, dass Mod4R ausnahmsweise vom Ringfinger getippt wird. > > Du meinst M4L, oder? Ja, richtig. > Um das hier zu berücksichtigen, müsste die Handverschiebung von M3L-M4L > erhalten bleiben, d.h. wir müssten komplett auf Trigramme wechseln (teuer). Da braucht man noch keine Trigramme. Die Idee mit virtuellen Tasten ist ja gerade, das gleichzeitige Drücken von Mod3L und Mod4 wie einen einzigen Tastendruck zu behandeln. > Ein Gedanke, den ich noch hatte ist, bei uB die Fingerkollision von u und > shift-L stärker zu werten als bei Bu, weil shift etwas früher gedrückt und > gelöst wird als b. > > …ich glaube allerdings, die Idee ist auch von dir ;) 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. > In den Bigrammen tut eine zusätzliche if-Abfrage nicht sehr weh. In den > Trigrammen wäre das etwas anderes… :) Auf die Gefahr hin, dir auf die Nerven zu fallen: Vielleicht solltest du die N-gramm-Strafpunkte und -häufigkeiten in simplen Matrizen tabellieren. Dann ist die Auswertung im wesentlichen ein Skalarprodukt zwischen Strafpunkten und Häufigkeiten, und sowas rechnet sich gut und schnell, auch wenn in den Matrizen viele Nullen stehen die man unnütz abarbeitet. Ich mache das so ähnlich, und kann auch mit Trigrammen einige hundert lokal optimale Tastaturen pro Minute berechnen. Es würde mich wundern wenn es bei den numerischen Erweiterungen für Python nicht etwas gäbe, mit dem man zumindest bis auf eine Grössenordnung daran heran kommt. Andreas
