Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
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.
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
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.
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
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
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Hi Martin, On Wednesday 20 October 2010 22:51:12 Martin Roppelt wrote: 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. Ja, natürlich, es wird eine stetige Beibehaltung der Grundstellung gelehrt. Das Tippen mit schwebenden Händen ist interessant und auch möglich (neulich hatte mir jemand erzählt er hat Qwertz über 2-Finger-System gelernt, Finger dazugenommen – und irgendwann hat er das blind gemacht, ohne sich dabei an irgendwelche „Regeln“ zu halten), aber schwieriger (zu lernen). Das war bei mir auch so. Der Nachteil war, dass ich nie wirklich blind tippen konnte, weil ich alle paar Wörter meine Handhaltung prüfen musste („ist die Taste wirklich da?“). Der Vorteil war, dass die Haltung etwas angenehmer war als die Starre, weil eben die Hände sich stetig etwas bewegt haben. Solche Bewegungen ließen sich dann auch abbilden. Werden sie dann Standard? Wird dann gleichzeitig auf „normale“ und diese Schreibweise optimiert? Btw finde ich die starre besser, die andere mag allerdings mehr Möglichkeiten eröffnen, ergonomisch zu schreiben (oder auch nicht …), fragt sich dann nur, ob das dann wirklich noch ergonomisch ist. Ich denke, um das zu diskutieren ist die Liste hier da. Ich habe keine Ahnung, wie viele Leute hier starr oder schwebend tippen. Ich finde an der Starren v.a. gut, dass ich sie schnell lernen konnte. Aber gerade bei 2-mod-Griffen breche ich aus ihr aus, und ich denke mit mehr Schreibpraxis im starren tippen werde ich an noch mehr Stellen aus ihr ausbrechen. Mein Qwertz hatte 10 Jahre mit kontinuierlich viel Tippen, um sich zu entwickeln, mein Neo hat bisher nichtmal ein Jahr. 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. Macht Sinn. Dann schau ich das mal genauer an. Danke! Liebe Grüße, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. - Arne (http://draketo.de) signature.asc Description: This is a digitally signed message part.
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
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
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Hi Andreas, On Wednesday 20 October 2010 22:49:01 wettstein...@solnet.ch wrote: 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. Stimmt. Für eine extrem einfache max() Funktion sähe mein Korpus in emacs in etwa so aus: def max(l): ges = 0 for num in l: ges += num tabtabrettab ges … tab muss auf eine Daumentaste :) 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. Das stimmt. Würde ich eigentlich dann auch so machen (ist aber in switch_key noch nicht drin). 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 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. Vielleicht kann emacs das auch direkt (müsste über einen hook gehen – irgendwie :) ). Da ich fast alles auf emacs umstellen kann (auch mein Mailprogramm), müsste ich so alle Daten sammeln können. 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. Jupp. Aber Neora könnte auch recht damit haben, dass ein gutes Layout das unnötig machen sollte. 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. Das würde dann den einen Sonderfall abfangen. Wenn es nicht allzu viele davon gibt, sollte es gehen, ja. 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 :) Das ist nämlich effektiv das, an dem ich gerade dransitze und das ich genau jetzt korrekt machen kann. Auf die Gefahr hin, dir auf die Nerven zu fallen: Vielleicht solltest du die N-gramm-Strafpunkte und -häufigkeiten in simplen Matrizen tabellieren. Damit fällst du mir definitiv nicht auf die Nerven. Ich habe den Port auf python2 (branch: py2) ursprünglich genau dafür gemacht (es gibt scipy noch nicht für python3, und das kann effiziente Matrizenrechnung, allerdings nur in 2D). Allerdings kommt scipy zum Glück bald für py3 (numpy ist schon da). Ich habe allerdings noch kein effizientes System im Kopf, um das sauber zu machen. Wie hast du das implementiert? 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? 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. *selbst testen will* :) Ich muss nur noch ein geeignetes Schema finden, um alle Kostenfunktionen auf Matrizenoperationen umzuschreiben. 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. Gibt es: SciPy. Noch effizienter mit scipy.weave (C++ in Python). Aber halt bisher nur in python2 (vermutlich nur noch ein paar Wochen lang :) ). Dazu, es im Python2 branch zu testen, bin ich durch pypy erstmal nicht gekommen (weil es im Gegensatz zu pypy Umstrukturierungen benötigt). Hoffentlich komme ich in 2 Wochen oder so dazu (jetzt wird es erstmal etwas turbulent…). Liebe Grüße, Arne -- A man in the streets faces a knife. Two policemen are there it
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
On Tuesday 19 October 2010 22:09:15 Florian Janßen wrote: Am 19.10.2010 22:07, schrieb Martin Roppelt: wettstein...@solnet.ch schrieb: Hier müsste man alledings noch berücksichtigen, dass Mod4R ausnahmsweise vom Ringfinger getippt wird. Ringfinger? Ich nehme dafür immer den Daumen … (naja, gut, es ist ein Laptop) hier auch Daumen (ausgewachsene 08/15 Tastatur) Vermutlich Mod4*L* :) Liebe Grüße, Arne -- Ich hab' nichts zu verbergen – hab ich gedacht: - http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen signature.asc Description: This is a digitally signed message part.
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Hi Andreas,
Danke für dein Review! Es hat mich auf viele neue Ideen gebracht.
On Tuesday 19 October 2010 21:36:47 wettstein...@solnet.ch wrote:
Bisher wird allerdings nur shift berücksichtigt (bzw. Großbuchstaben),
daher dürften wir noch ein paar Kollisionen auf dem kleinen Finger
verpassen (bei Sonderzeichen auf der dritten oder höheren Ebenen).
Ich arbeite gerade daran, das zu ändern.
Schau die Zeichenhäufigkeiten im Korpus an. Für Englisch noch könnte es
sich lohnen, den Apostrophen mitzunehmen, da er wegen Genitiv-s einen
bevorzugten Kollisionsgegner hat. Ansonsten zweifle ich, dass es sich
rentiert, weitere Zeichen mitzunehmen.
Ich denke, es eignet sich für Sonderlayouts, z.B. ein Kernel-Hacker-Layout,
das auf den Linux kernel optimiert ist. [] könnte da einige Kollisionen
bringen ({} und () nicht, weil davor und danach meist Leerzeichen kommen).
Für Leute, deren Job Kernelprogrammierung ist, könnte sich die Optimierung
lohnen.
Genauso für Leute, die viel Griechisch oder mathematische Symbole schreiben.
Zudem müsste man erst die
Typographie im Korpus verifizieren: Was ist wirklich ein Bindestrich,
was sollte eigentlich ein Gedankenstrich sein? Was sollte anstelle der
geraden doppelten ASCII-Anführungszeichen stehen, was anstelle des
geraden ASCII-Apostrophen?
Dafür brauchen wir „nur“ einen korrekten Korpus :)
Es geht schließlich darum, das tippen zu können, was im Korpus steht.
Konkret ist meine Frage, ob das hier die korrekte Aufteilung von Ψ∃ ist:
Wie tippst du Mod3L+Mod4L? Mit den offiziellen Neo-Positionen würde ich
dazu Klein- und Ringfinger nehmen, für Mod3L und Mod4L einzeln aber
jeweils den kleinen Finger.
Ich nehme auch Kleinen- und Ringfinger, daher ist die Aufteilung sicher nicht
perfekt. Ideal fände ich es ja, alle Modifier auf den Daumen zu haben. Dann
ware M6 M3L+M4R.
Man könnte Modifierpaare wie virtuelle Tasten behandeln, die von einem
virtuellen Finger bedient werden.
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.
Solche Bewegungen ließen sich dann auch abbilden. Beispielweise könnten die
Finger durch Bewegungen der Hand verschoben werden: Wenn ich M3 drücke, ist
meine Hand eine Taste nach links verschoben, so dass M4 auf dem Ringfinger
liegt. Kosten würden dann allerdings nur noch durch Verzerrungen der Hand
kommen, nicht mehr durch feste Kosten pro Taste.
Die nötigen Änderungen wären vermutlich auch nicht allzu groß. Selbst die
Kosten pro Taste könnten wir weiternutzen, indem sie einfach mit der Hand
mitwandern. Nach einem s wäre ein k also günstiger als nach einem n.
# Die Modifier beider Zeichen miteinander
'⇩⇙', M3L + M4R
'⇩⇘', M3L + M3R
'⇚⇙', M4L + M4R
'⇚⇘', M4L + M3R
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?
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).
Alternativ könnten wir aus den Bigrammen für jedes Zeichen die
Wahrscheinlichkeit dafür errechnen, dass die Hand beim ersten Zeichen
verschoben ist, und damit dann alle Bigramme anpassen. Mehr als eine Spalte
verschiebung dürfte allerdings zumindest bei 10-Finger-Tippen unnötig sein.
Bei einhändiger Bedienung sieht es da schon ganz anders aus…
# Die Modifier mit dem anderen Modifier der Taste
# sortiert – sollte das in beide Richtungen gehen, also 0.5*(m3-m4,
m4-m3)? '⇩⇚', M3L + M4L
'⇘⇙', M3R + M4R
Das sind die Einzeltastengewichte für Mod6L und Mod6R. Die Summe der
realen Einzeltastengewichte ist wäre ein guter Ausgangspunkt, eine
Reduktion dafür, dass beide Tasten in mit einer Handbewegung erreicht
werden, wäre zu überlegen.
Stimmt. Die einfachen Kosten pro Taste sind übrigens schon drin:
COST_LAYER_ADDITION = [0, 15, 12, 10, 27, 22]
Das hatten wir auch schon im bisherigen Optimierungsdurchgang.
Die Bigrammaufteilung kommt nur in Fingerwiederholungen, Bewegungsmustern,
Handwechsel nach unbalance und Zeilenwechseln zum Tragen.
Bei M4-M3 bedeutet das aktuell eine automatische Fingerwiederholung
(fälschlicherweise). Da eine Fingerwiederholung 256 Strafpunkte gibt, sollte
das um etwa Faktor 32 reduziert werden, so dass es insgesamt immernoch ein
Vorteil ist, eine Taste zu haben, auch wenn sie auf Ebene 5 ist.
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 ;)
Um es zu aktivieren müsste ich jetzt nur noch 2 auskommentierte Codezeilen
wieder reinnehmen :)
# Die Modifier mit den
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Bisher wird allerdings nur shift berücksichtigt (bzw. Großbuchstaben), daher dürften wir noch ein paar Kollisionen auf dem kleinen Finger verpassen (bei Sonderzeichen auf der dritten oder höheren Ebenen). Ich arbeite gerade daran, das zu ändern. Schau die Zeichenhäufigkeiten im Korpus an. Für Englisch noch könnte es sich lohnen, den Apostrophen mitzunehmen, da er wegen Genitiv-s einen bevorzugten Kollisionsgegner hat. Ansonsten zweifle ich, dass es sich rentiert, weitere Zeichen mitzunehmen. Zudem müsste man erst die Typographie im Korpus verifizieren: Was ist wirklich ein Bindestrich, was sollte eigentlich ein Gedankenstrich sein? Was sollte anstelle der geraden doppelten ASCII-Anführungszeichen stehen, was anstelle des geraden ASCII-Apostrophen? Konkret ist meine Frage, ob das hier die korrekte Aufteilung von Ψ∃ ist: Wie tippst du Mod3L+Mod4L? Mit den offiziellen Neo-Positionen würde ich dazu Klein- und Ringfinger nehmen, für Mod3L und Mod4L einzeln aber jeweils den kleinen Finger. Man könnte Modifierpaare wie virtuelle Tasten behandeln, die von einem virtuellen Finger bedient werden. Im Beispiel oben besteht der virtuelle Finger aus linkem Klein- und Ringfinger. Für die viruelle Taste überlegt man sich dann die Strafpunkte in Kombination mit allen anderer realen und virtuellen Tasten. Die gedankliche Einführung der virtuellen Taste führt noch nicht zu einer Herleitung der Bewertung aus bekannten Bewertungen, denn das geht eben nicht, weil Modifierkombinationen anders getippt werden als Modifier einzeln. Es ist lediglich eine nützliche Abstraktion, vermutlich auch nett zum implementieren, zumindest in meinem Optimierer wäre es so. # Die Modifier beider Zeichen miteinander '⇩⇙', M3L + M4R '⇩⇘', M3L + M3R '⇚⇙', M4L + M4R '⇚⇘', M4L + M3R Das ist das Bigrammgewicht Mod6R-Mod6L. Hier müsste man alledings noch berücksichtigen, dass Mod4R ausnahmsweise vom Ringfinger getippt wird. # Die Modifier mit dem anderen Modifier der Taste # sortiert – sollte das in beide Richtungen gehen, also 0.5*(m3-m4, m4-m3)? '⇩⇚', M3L + M4L '⇘⇙', M3R + M4R Das sind die Einzeltastengewichte für Mod6L und Mod6R. Die Summe der realen Einzeltastengewichte ist wäre ein guter Ausgangspunkt, eine Reduktion dafür, dass beide Tasten in mit einer Handbewegung erreicht werden, wäre zu überlegen. # Die Modifier mit den dazugehörigen Grundtasten '⇩h', shiftL + h '⇚h', M4L + h '⇙e', M4R + e '⇘e', M3R + e # Die Modifier mit der jeweils anderen Grundtasten '⇩e', shiftL + e '⇚e', M4L + e 'h⇙', h + M4R 'h⇘', h + M3R Mod3L, nicht shiftL, oder? Das sind Bigrammgewichte Mod6L mit Buchstabentaste und Buchstabentaste mit Mod6R mit Buchstabentasten. Auch hier müsste man noch bedenken, dass Mod4L irregulär getippt wird. # Die Grundtasten (auf Ebene 1) 'he' Das wenigstens ist klar. Aber, wie gesagt, schon Ebene 3 lohnt sich kaum zu berücksichtigen, Ebene 5 und 6 kannst du für die Optimierung vergessen. Andreas
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Am 19.10.2010 22:07, schrieb Martin Roppelt: wettstein...@solnet.ch schrieb: Hier müsste man alledings noch berücksichtigen, dass Mod4R ausnahmsweise vom Ringfinger getippt wird. Ringfinger? Ich nehme dafür immer den Daumen … (naja, gut, es ist ein Laptop) hier auch Daumen (ausgewachsene 08/15 Tastatur) Florian
[Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
On Tuesday 28 September 2010 23:50:27 Arne Babenhauserheide wrote: Bisher wird allerdings nur shift berücksichtigt (bzw. Großbuchstaben), daher dürften wir noch ein paar Kollisionen auf dem kleinen Finger verpassen (bei Sonderzeichen auf der dritten oder höheren Ebenen). Ich arbeite gerade daran, das zu ändern. Und dafür brauche ich Hilfe. Ich habe nämlich etwas den Überblick verloren. Ich habe eine Liste von Bigrammen und teile sie in Bigrammen aus ihren Grundtasten und die jeweils dazugehörigen Modifier auf. Die Modifier sind: shift L/R: ⇧/⇗ M3 L/R: ⇩/⇘ M4 L/R: ⇚/⇙ Die Eingabe-Bigramme sehen so aus: [(36, ab), (24, Ab), (16, aB), (10, AB), (6, ¾2), (4, (}), (2, Ψ∃), (1, q)] Jetzt werden die aufgeteilt, und ich bin nicht ganz sicher, ob die Ausgabe korrekt ist… Die meisten sind klar, aber v.a. Ψ∃ macht mir Probleme. Konkret ist meine Frage, ob das hier die korrekte Aufteilung von Ψ∃ ist: # Die Modifier beider Zeichen miteinander '⇩⇙', M3L + M4R '⇩⇘', M3L + M3R '⇚⇙', M4L + M4R '⇚⇘', M4L + M3R # Die Modifier mit dem anderen Modifier der Taste # sortiert – sollte das in beide Richtungen gehen, also 0.5*(m3-m4, m4-m3)? '⇩⇚', M3L + M4L '⇘⇙', M3R + M4R # Die Modifier mit den dazugehörigen Grundtasten '⇩h', shiftL + h '⇚h', M4L + h '⇙e', M4R + e '⇘e', M3R + e # Die Modifier mit der jeweils anderen Grundtasten '⇩e', shiftL + e '⇚e', M4L + e 'h⇙', h + M4R 'h⇘', h + M3R # Die Grundtasten (auf Ebene 1) 'he' Wenn ja, dann sollte der folgende Doctest korrekt sein: [(36, 'ab'), (24, '⇗b'), (24, '⇗a'), (24, 'ab'), (16, '⇧b'), (16, 'a⇧'), (16, 'ab'), (10, '⇧b'), (10, '⇗⇧'), (10, '⇗b'), (10, '⇗a'), (10, 'a⇧'), (10, 'ab'), (6, '¾2'), (4, '⇩⇘'), (4, '⇩n'), (4, '⇩e'), (4, '⇘e'), (4, 'n⇘'), (4, 'ne'), (2, '⇩⇚'), (2, '⇩⇙'), (2, '⇩⇘'), (2, '⇩h'), (2, '⇩e'), (2, '⇚⇙'), (2, '⇚⇘'), (2, '⇚h'), (2, '⇚e'), (2, '⇙e'), (2, '⇘⇙'), (2, '⇘e'), (2, 'h⇙'), (2, 'h⇘'), (2, 'he')] Liebe Grüße, Arne -- Ein Würfel System - einfach saubere Regeln: - http://1w6.org signature.asc Description: This is a digitally signed message part.
