On Friday 22 October 2010 20:40:27 wettstein...@solnet.ch wrote: > 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».
Das stimmt auch wieder :) > > > 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. Das klingt klasse! Das Gefühl hatte ich nämlich auch schon, dachte aber, dass es wohl eher eine fixe Idee ist. Aber nachdem du sie nun bereits durchdacht hast, sollte ich sie wohl mal implementieren :) if is_left(pos1) is is_left(pos3) is not is_left(pos2): (add bigram cost) > 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. Das könnten wir machen, aber erstmal kommt es nur in die TODO :) > 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. Damit könnte ich also einfach den Code wiederverwenden. Allerdings müsste dann alles über trigramme laufen, und die sind nicht wirklich schnell (weil viel zu viele…). > 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. Ich hoffe, dass da die Auswirkungen ausreichend gering sind. Nur wenn die 2. Stelle (fast) wegfällt, sollte die 3. viel ausmachen. Zumindest, wenn die Auswirkungen ausreichend schnell fallen. Wenn das nicht der Fall sein sollte, wird das ganze hier *sehr* teuer… aber wenn es sein muss, muss es sein. Ich fühle mich gerade in meine Physik-Vorlesungen zurückversetzt: Quadrupole sind nur dann direkt sichtbar, wenn die Bipole sich aufheben (heißt: Die 2. Ableitung ist nur relevant, wenn die 1. wegfällt). Und ja, das muss man trotzdem rechnen… :) > > 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). …dafür brauche ich vermutlich etwas länger… (code wirklich verstehen). > > 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). Matrizen in der Art habe ich inzwischen einmal getestet, allerdings suboptimal implementiert (alle Zeichen in der Matrix, statt nur Grundlinie + vorher die ngram-listen umschreiben, was ich eh machen muss). Mal sehen, was passiert, wenn ich die Matrizen nicht zu groß mache… (perfektionismus ist gerne mal überhaupt nicht perfekt :) ). Danke für die Tipps! Liebe Grüße, Arne -- Konstruktive Kritik: - http://draketo.de/licht/krude-ideen/konstruktive-kritik
signature.asc
Description: This is a digitally signed message part.
