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
> 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 :) Bei mir war es ein Überlegung, kein Gefühl, bis auf einmal, als ich «debug» getippt habe – das sind bei meiner Belegung vier Handwechsel, d, b und g liegen auf aber dem gleichen Finger. Ich tippe oft «debug», und meistens fällt mir nichts dabei auf. > 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…). Wichtiger als die Wiederverwertung von Code ist, dass man nicht zu viele Parameter einführt. Die wachsen einem auch ohne Trigramme schon über den Kopf. Die Rechenzeit geht allerdings in der Tat merklich rauf. Vielleicht kann man Abschätzungen machen. Wenn man die Belegung zweier Tasten vertauscht und die Aufwandsänderung aufgrund von Einzeltastengewichten und Bigrammen berechnet hat, könnte man so vielleicht beurteilen, ob die Trigramme am Ergebnis (Verbesserung oder Verschlechterung) überhaupt noch etwas ändern können. Eine gute, schnelle Abschätzung zu machen ist vermutlich nicht einfach. Mit C++ kann man die Trigramme auch mit Gewalt noch in akzeptabler Zeit behandeln, daher bin ich bisher bei der Holzhammermethode geblieben. > > 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. Ich denke, wenn man mit QWERTZ «oj.» tippt hat den Paradefall: Zwei harmlose Bigramme, ein günstig gelegener mittlere Buchstabe, aber eine «Kollision» mit weitem Sprung zwischen erstem und letztem Zeichen. > Wenn das nicht der Fall sein sollte, > wird das ganze hier *sehr* teuer… aber wenn es sein muss, muss es sein. Das ist «nur» noch eine Verdoppelung der Rechenzeit. > 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… :) Ja, wir machen hier eine Entwicklung des Tippaufwands nach Ordnung der n-Gramme. Wenn wir verlangen, dass die Kosten von allen n-Grammen nichtnegativ sind, muss das sogar konvergieren. Leider sind bei mir manche Kosten negativ… Andreas
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 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 ret 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 k
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 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
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
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
On Monday 18 October 2010 23:04:28 Arne Babenhauserheide wrote: > 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. Kurz ein Update: Ich habe für Bigramme inzwischen alle Ebenen integriert (Vorsicht: Der aktuelle tip berechnet dadurch die Layouts inzwischen etwas anders als config-2010-09-19.1). Nachdem das dann ein gutes Stück langsamer war, habe ich mich an den profiler gesetzt und den Code nochmal ein paar Stunden lang optimiert. ## Ergebnis ### Vorher $ time ./check_neo.py -v --evolve 1000 … real13m37.446s user12m29.945s sys 0m1.776s ### Jetzt $ time ./check_neo.py -v --evolve 1000 … real9m53.473s user9m49.648s sys 0m0.280s Pypy (Zweig: py2-pypy) spart nochmal etwa 5-20% Rechenzeit (meine händische Optimierung scheint ein paar der Optimierungen von pypy vorwegzunehmen und python3 ist bei viel unicode schneller als python2.6). $ time pypy-c-jit-78030-linux/bin/pypy ./check_neo.py -v --evolve 1000 … real9m8.582s user8m39.048s sys 0m0.431s (der Test hier allerdings mit etwas mehr Systemlast als die anderen. Ein py3- Test kurz danach brauchte 10m39.052s, user: 9m48.295s – etwa 1min 15s länger ⇒ ~12% reale Zeitersparnis). Im Vergleich zu Python 2.6 spart pypy etwa 50 % Rechenzeit: $ time python ./check_neo.py -v --evolve 1000 … real19m12.752s user17m53.741s sys 0m1.264s … dachte, das könnte euch interessieren :) 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
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
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
[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.
