[email protected] wrote: >> Wobei mir da gerade noch auffällt: Wie genau behandelst du Großschreibung >> wirklich sauber? > > Für die Einzeltastenwertung veranschlage ich für Shift einfach die > Kosten für den zusätzlichen Tastendruck. Das spielt nur dann eine > Rolle, wenn Shift links und rechts nicht symmetrisch sind, und daher die > linke und rechte Shifttaste unterschiedlich viel kosten.
Das habe ich auch so. > Die Bigrammwertung mache ich so: Ich gehe von Bigrammkosten für alle > Tastenpaare (i,j) aus. Will ich dann «Ab» bewerten, und A liegt auf > Taste i, das Shift gegenüber auf Taste k, und b auf Taste j, dann > veranschlage ich die Summe Kosten für das Bigramm (i,j) und (k,j). Für > «aB», falls l die Shifttaste gegenüber von Taste j ist, veranschlage ich > die Summe Kosten für das Bigramm (i,j) und (i,l), für «AB» schliesslich > (i,j)+(k,j)+(i,l). Das ist schön sauber – übernehme ich so. Danke! Jetzt (nach einer 2h debug session) sollte es auch endlich passen… Dein Zwischen-Layout: # 0.833993079119 % finger repeats in file 2gramme.tx Mein Zwischenlayout: # 2.13121649096 % finger repeats in file 2gramme.txt NordTast: # 1.52732143654 % finger repeats in file 2gramme.txt Neo: # 4.91505750212 % finger repeats in file 2gramme.txt Naja, und Qwertz :) # 7.40712552483 % finger repeats in file 2gramme.txt >> - Die Kollision shift-erster Buchstabe stärker, weil das Shift meist >> schon etwas früher gelöst wird als der Buchstabe (zumindest bei mir). > > Ich hatte sowas in der Art mal, hab's aber bei einer Codevereinfachung > verloren. Grundsätzlich ist es sinnvoll, Shift-Kollisionen anders zu > gewichten als normale; im Fall «Ab» eher schwächer, im Fall «aB» eher > stärker, aus dem von dir genannten Grund. Ich lasse es erstmal einfach, habe mir aber ein Todo notiert. Danke nochmal! Mein Optimierer läuft jetzt ein paar Runden; mal sehen, was rauskommt :) Liebe Grüße, Arne
