Re: [Neo] Automatische Optimierung
Ich würde persönlich erstmal Shift ignorieren (ist das der Bug?) Klar, nur etwa 5% der Zeichen sind Großbuchstaben, und ihre Häufigkeit ist durch den Text, nicht durch die Belegung vorgegeben. Das spricht dafür, sie zu ignorieren. Andererseits, falls man sich wegen einem Prozent mehr oder weniger Fingerkollisionen Gedanken macht kommt man um die Berücksichtigung von Shift kaum herum. Zum Beispiel: Eidur 251.831 Gesamtaufwand 190.763 Lageaufwand links rechts 0.808 Kollisionen18.900 Shift-Kollisionen ob 9.8 13.0 äuocj khlmvx70.849 Handwechsel21.786 Shift-Handwechsel mi 36.6 31.2 aietp gdnsrß14.092 Einwärts 56.533 Shift-Einwärtsun 7.5 8.6 .,üöq zbwfy 11.976 Auswärts2.781 Shift-Auswärts sum 53.9 52.7 Finger 11.9 12.3 19.2 10.5 | 16.5 14.8 10.5 10.9 Shift 4.5 2.1 Hier verdoppelt sich die Anzahl Kollisionen, sobald man die Kollisionen mitzählt, bei denen der gleiche kleine Finger erst Shift drückt und direkt danach eine andere Taste anschlagen muss oder umgekehrt (oben Shift-Kollision genannt, die Zahl ist auf die Zahl der Bigramme mit Großbuchstaben bezogen). Die Lagepunkte sind nach meiner Meinung in erster Linie ein Werkzeug um das Programm in bestimmte Bahnen zu zwingen und können so auch nicht Gegenstand einer demokratischen Umfrage werden (!). Ich sehe das technokratischer. Wenn die Lagepunkte nicht interessieren lässt man sie weg; wenn sie interessieren sollten sie vernünftig sein und angemessen gewichtet werden, sonst vermasseln sie nur die automatische Optimierung. 10 238.143 Gesamtaufwand 189.086 Lageaufwand links rechts 0.797 Kollisionen 6.650 Shift-Kollisionen ob 8.1 13.3 cüo., bgmlfß70.905 Handwechsel23.395 Shift-Handwechsel mi 39.2 32.2 teaiu hdnrsx14.225 Einwärts 66.138 Shift-Einwärtsun 6.0 7.8 jqäöy kpwvz 11.798 Auswärts3.817 Shift-Auswärts sum 53.3 53.3 Finger 14.0 16.6 9.0 13.7 | 16.3 13.8 12.1 11.2 Shift 4.8 1.8 So eine Ähnliche habe ich mehrmals gehabt. Ich bekomme aber: === cüo., bgmlfß teaiu hdnrsx jqäöy kpwvz Lagepunkte145 Fingerwiederholung 0.770 % Handwechsel... 74.543 % Einwärtsbewegung.. 14.958 % Auswärtsbewegung.. 9.730 % Fingerverteilung: 9.17 16.55 9.01 13.74 | 16.35 13.76 12.06 9.36 Deine Prozente Wiederholung, Wechsel, Einwärts, Auswärts summieren sich nicht zu 100%. Das stört irgendwie. Bei Kollisionen zähle ich Mehrfachanschläge (also zum Beispiel «ll») nicht mit. Ich gebe sie auch nicht mit der Tastatur, sondern mit der Korpusstatistik aus, denn sie sind eine Eigenschaft des Korpus, nicht der Belegung. Die Unterschiede kommen vermutlich von den Bigrammhäufigkeiten. bigramme-de.txt von deiner Homepage sieht deutlich anders aus als Karls 2gramme.txt. Du verwendest die 1M Datei, Karl die 3M Datei. Mit sentences.txt aus der 100k-Datei bekomme ich eine ähnliche Verteilung wie Karl. Wenn man eine Eigenschaft optimiert, leidet vielleicht eine andere. Wenn es anders wäre würde ich dem Optimierer nicht trauen. Andreas
Re: [Neo] Mod4 und Bild↑ und Bild↓ (was: R e: Miniguru, programmierbare Tastatur)
2009/12/23 Erik Streb del Toro m...@erikstreb.de: Stefan Ritter schrieb am 23.12.2009 09:32: http://www.guru-board.com/german/features_de Aha, wie man hier¹ sieht, haben hier Profis festgelegt, dass Bild↑ und Bild↓ nicht häufig hintereinander betätigt werden (kein Bigramm sind). Das steht im Text unter dem Bild¹. Ich würde sagen die leidliche Ebene4-Diskussion hat somit ein extern entschiedenes Ende gefunden. Gut oder? Das ist das Weihnachtsgeschenk an alle Neo-Nutzer: Neo 2 ist fertig! inspiriert von der guru-tastatur, hier ein vorschlag (wenn ich den jetzt leia-guru nenne bekomm ich eine aufn deckel *g*): ⇱⌫↑⌦⇞ ⇲←↓→⇟ ⌧⎀↲⇥↶ steuerkreuz, backspace/delete wie im rc1, home/end pgup/pgdn so wie auf dem echten block, escape für die vi-user neben m4l, undo auf z, tabenter als bigramm, tab auf der rechten seite. wenn das echt nichts wird, müssen wir dann wohl oder übel bei der rc1-variante bleiben. glg, daniel -- myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
[Neo] Wie groß muss ein Korpus sein?
Damit die Beurteilung einer Tastatur nicht zu sehr durch zufällige Variation der Zeichen- und Bigrammhäufigkeiten beeinflusst wird, muss der Korpus groß genug sein. Die Frage ist, wie groß. Die Beurteilung einer Tastatur wird durch eine Zahl ausgedrückt. Man kann sich überlegen, dass für einen sehr große Korpora der relative statistische Fehler dieser Zahl reziprok zur Wurzel der Größe eines Korpus ist. Dieses qualitative Verhalten sollte nicht vom Bewertungsschema und der gegeben Tastatur abhängen; der Vorfaktor kann das aber durchaus. Um den Vorfaktor zu bekommen habe ich zwei Tastaturen, eine (gemäß meinen aktuellen Kriterien) besonders gute und eine besonders schlechte, mit verschiedenen Korpora bewertet und aus den Einzelergebnissen den relativen Fehler (Standardabweichung durch Mittelwert) bestimmt. Die Korpora habe ich aus dem Leipziger 1M-Korpus gewonnen, indem ich diesen einmal in 1000 Files zu je 1000 Zeilen und einmal in 100 Files zu je 1 Zeilen aufgespaltet habe. Resultat: Mittel rel. Fehler Files Zeilen Tastatur 236.353 0.00140541 1001 optimiert 236.357 0.00394096 10001000 optimiert 984.445 0.000574423 1001 pessimiert 984.446 0.0018825 10001000 pessimiert So ein 1-Zeilen-File hat etwa 1.1 MByte, und der relative statistische Fehler der Bewertung ist im Promillebereich. Wenn wir uns als Ziel setzen, den statistischen Fehler unter einem Promille zu halten (die Willkür im Bewertungschema wird viel größer sein als das), ist ein Korpus von 3 MByte also groß genug. Andreas
Re: [Neo] Wie groß muss ein Korpus sein?
Mittel rel. Fehler Files Zeilen Tastatur 236.353 0.00140541 1001 optimiert 236.357 0.00394096 10001000 optimiert 984.445 0.000574423 1001 pessimiert 984.446 0.0018825 10001000 pessimiert So ein 1-Zeilen-File hat etwa 1.1 MByte, und der relative statistische Fehler der Bewertung ist im Promillebereich. Wenn wir uns als Ziel setzen, den statistischen Fehler unter einem Promille zu halten (die Willkür im Bewertungschema wird viel größer sein als das), ist ein Korpus von 3 MByte also groß genug. Hervorragend, wenn ich das sagen darf… Ich bin mich aber immer noch im Nacken am Kratzen wegen den unterschiedlichen Ergebnissen unserer Auswertungsversuche. Ganz habe ich es nicht verstanden. Irgendwie kann es ja nicht sein, dass wir aus einem identischen Textkorpus unterschiedliche Bigramme ziehen. (Ich habe allerdings alle Bigramme in Kleinbuchstaben gezogen, und Komma und Punkt als Buchstaben behandelt, Karl hatte das etwas anders gehandhabt, ich glaube, das erklärt zum Teil den Unterschied. Und ich habe die Shift-Taste einfach ignoriert. Oder ich habe irgendeinen unverzeihlichen Fehler gemacht, ich finde ihn nur nicht). Nach deiner Berechnung müssen wir also eigentlich das gleiche herausbekommen, ob wir nun die 1M oder die 3M Datei benutzen, richtig? Das heißt, der Unterschied zwischen unseren Ergebnissen ist eher systematisch bedingt als dass er auf unterschiedlicher Korpusgröße beruht. Nun hieß in diesem Fall 1M (im Leipziger Korpus) „eine Million Zeilen“ oder so, nicht „eine Million Bytes“. Demnach wäre die 1M Datei also reichlich groß genug, ich hoffe, ich habe hier nichts missverstanden. Es ist jedenfalls angenehm zu wissen, in Zahlen also, dass die Korpusgröße ab einer gewissen Größe aufwärts nicht mehr so viel bringt (also, vermutet wurde das ja schon mehrmals), und es ist schön, eine qualifizierte Schätzung über die mutmaßliche Fehlergröße zu haben. Alle Achtung vor deinen hartnäckigen Bemühungen, der Wahrheit näher zu kommen. Übrigens (hier etwas off topic): Ich habe es so verstanden, dass man im allgemeinen gerne sähe, dass es zu Vergleichszwecken EINEN Korpus gäbe, auf den man sich beziehen könnte. Ich nehme an, dass man daraus auch eine Liste aller Bigramme machen kann, über die alle sich einig sind, so schwierig ist das ja nun auch nicht. Da muss man sich aber einig werden, ob Punkt und Komma Teil der Bigramme sein sollen, oder gar andere Zeichen, die auf einer anderen Ebene liegen usw. Ich hatte das Alphabet gleichgesetzt mit den 32 Tasten, die verteilt werden sollen. Letztendlich muss man auch erörtern, ob das mit der Shift-Taste wirklich ein Kriterium ist, um eine Tastatur der anderen Vorzuziehen. Ich meine ja hier, wenn ich links Shift drücke, und rechts das „n“ (um ein großes N zu schreiben), und danach den linken Kleinfinger sofort wieder betätige, dann ist das nicht ganz so schlimm als wenn ich den linken kleinen Finger mitten drin in einem Wort zweimal hinter einander benutzen müsste. Die Frage ist, ob es wirklich überhaupt schlimmer ist, als wenn ich nach dem großen N den Zeigefinger benutzen würde. Und wenn es schlimm ist, wie schlimm ist es dann (in % der normalen Strafpunkte ausgedrückt). Ich meine, eines ist, dass jemand sich wünscht, grundsätzlich auf die Shift-Taste zu gucken, das ist ja ein legitimer Wunsch, ein anderes ist, wie sehr dieses Hingucken die Bewertung beeinflusst. Das ist mit dem wie mit der Fingerverteilung. Hier gibt es noch Klärungsbedarf, und zwar nicht von mir, denn ich bin ein überzeugter Shift-Tasten-Ignorierer, sondern von den übrigen Listenmitgliedern. Ulf
Re: [Neo] 26c3
Am Sonntag, den 27.12.2009, 17:19 +0100 schrieb Erik Streb del Toro: Benjamin Kellermann schrieb am 27.12.2009 15:02: Ich fänds super, wenn wir uns mal treffen. Ich bin aber leider nur am 29. und 30. da: http://dudle.inf.tu-dresden.de/neo_at_26c3/ Also sagt an, wann wollen wir uns treffen? Also ich bin heute auch nicht da, weil ich gerade erst nach Hause gekommen bin. eingetragen hat sich bis jetzt nur alex… Ich bin auf jeden Fall morgen um 9 am bcc, wer kommt noch? Ben
Re: [Neo] Wie groß muss ein Korpus sein?
Hallo Ulf, am Mon, 28 Dec 2009 22:24:38 schrieb Ulf: Irgendwie kann es ja nicht sein, dass wir aus einem identischen Textkorpus unterschiedliche Bigramme ziehen. (Ich habe allerdings alle Bigramme in Kleinbuchstaben gezogen, und Komma und Punkt als Buchstaben behandelt, Karl hatte das etwas anders gehandhabt, ich glaube, das erklärt zum Teil den Unterschied. Eine Beobachtung fiel mir seinerzeit auf, von der ich nicht weiß, ob sie noch aktuell ist. Einmal hattest Du Linux-Befehle beschrieben, mit denen sich eine Bigrammliste erstellen läßt (vielen Dank, sie waren mir hilfreich). Danach entstanden aus dem Wort Beispieltext die Bigramme: Be is pi el te xt Bei der von mir verwendeten Variante entstehen aus dem Wort Beispieltext die Bigramme: Be ei is sp pi ie el lt te ex xt Bei einem großen Textkörper fällt der Unterschied nicht ins Gewicht, da die Bigramme sich oft genug wiederholen. Neben der Zusammenfassung von Groß- und Kleinbuchstaben könnte die Beobachtung auf eine weitere Ursache für unterschiedliche Bigrammlisten hinweisen. Mit netten Grüßen Karl
Re: [Neo] Wie groß muss ein Korpus sein?
Am Mon, 28 Dec 2009 20:26:06 +0100 schrieb wettstein...@solnet.ch: Damit die Beurteilung einer Tastatur nicht zu sehr durch zufällige Variation der Zeichen- und Bigrammhäufigkeiten beeinflusst wird, muss der Korpus groß genug sein. Die Frage ist, wie groß. Je nachdem, welche Informationen aus dem Textkörper geholt werden sollen, kann ein größerer Textkörper erforderlich sein. Interessant könnte sein, einen Textkörper in einer Matrix abzubilden, die die Wahrscheinlichkeiten enthält, mit der ein Zeichen auf ein anderes folgt (bzw. ihm voraus geht). Zum Erzeugen solch einer Matrix (z. B. anhand einer Trigrammliste nach dem mittleren Zeichen sortiert) erscheint mir tatsächlich ein recht großer Textkörper erforderlich, wenn der Fehler im relevanten Bereich nicht zu hoch werden soll. Ich vermute einen Fehler von 2 % im relevanten Bereich beim 3-Millionen-Sätze-Textkorpus, bin mir aber unsicher. Kann man anhand der Fehlerbetrachtung für Bigramme auch auf eine für Trigramme schließen? Mit schönen Grüßen Karl
Re: [Neo] Wie groß muss ein Korpus sein?
Einmal hattest Du Linux-Befehle beschrieben, mit denen sich eine Bigrammliste erstellen läßt (vielen Dank, sie waren mir hilfreich). Danach entstanden aus dem Wort Beispieltext die Bigramme: Be is pi el te xt Bei der von mir verwendeten Variante entstehen aus dem Wort Beispieltext die Bigramme: Be ei is sp pi ie el lt te ex xt Das ist es! Jetzt kann ich von vorne anfangen! Danke! Dann ist meine ganze Arbeit für den Eimer! Was für eine Schande! Hätte ich das bloß früher gewusst… Ulf
