Ich habe ein kleines Python Skript geschrieben, um das Neo Tastaturlayout zu prüfen und mit kleinen evolutionären Codes zu schauen, ob es sinnvolle Möglichkeiten zur Verbesserung gibt.
Es braucht Python 3.
Update: Jetzt vollständig als Quellcode-Archiv verfügbar: Evolve Keyboard Layout.
Usage
- check_neo.py --help (display this text)
- check_neo.py --test (run doctests)
- check_neo.py [--file ] [--switch ] [-q] [-v]
run the script on the file.
--switch switches letters on the neo keyboard (lx,wq switches l for x and w for q).
-q removes the qwertz comparision.
-v adds the list of finger repeats.
- check_neo.py --evolve [-q]
randomly permutate keys on the Neo keyboard to see if a better layout emerges.
Für die evolutionären Codes braucht das Skript die Dateien "1gramme.txt" und "2gramme.txt".
Lizenz wie üblich GPL.
Design
- Der Code ist in die Abschnitte Constants, Imports, Helper functions, Cost functions und Evolution aufgeteilt.
- Daten als Listen, die der Tastatur entsprechen: Reihen und Spalten.
- Für jede Taste ein Tuple mit den verschiedenen Bedeutungen. Mods: (None, Shift, Mod3, Mod4, Shift+Mod3, Mod3+Mod4)
- find_key() -> (reihe, spalte, index)
- two_char_repeats_from_file() -> [iste mit allen 2 char repeats, auch mehrfach.
- two_chars_on_same_finger(keys) -> sind min 2 Buchstaben auf dem gleichen Finger? -> Finger
- Einfache Funktionen zum Austauschen.
- Eine Kostenfunktion -> Text + Layout = Kosten.
- Ein Layout mit Kosten: Zahl für jede Taste -> Exaktere Berechnung der Kosten der Änderung.
- Evolution durch Mutation und Kostenminimierung (switch miltiple times (3?) => keep if lower cost).
- Die Hauptarbeit der Mutation wird von der Funktion total_cost() übernommen.
Später
- "Kosten der Änderung" für die Austauschfunktion: Fingerwechsel, Seitenwechsel, ...
Vorgehensweise zur Optimierung
- Annahme: Es gibt eine Idealtastatur. Mit ihr können Gedanken ohne Zeitverlust und ohne Aufwand aufgezeichnet werden.
- Reale Tastaturen können sich dem Ideal immer nur annähern. Daher arbeiten wir mit „Kosten im Vergleich zur Idealtastatur“. Die Minimierung der Kosten gibt einen Hinweis darauf, wie eine der Idealtastatur möglichst nahe kommende Tastatur aussehen kann.
- Ein Programm kann nur die einfachsten Faktoren berücksichtigen, da es Quantisierung benötigt. Deshalb muss eine Optimierung von Menschen geprüft werden, und Ästethik und Intuition (also menschliches Feingefühle mit viel komplexerer Grundlage: Quantitative + Qualitative Faktoren) gelten mehr als reine Zahlenspielerei. Die Maschine kann aber Vorarbeit leisten und stupides Prüfen übernehmen.
- Die deutsche Standardtastatur gilt als „Infrastruktur“. Das Layout muss auf ihr funktionieren.
- Als Daten-Grundlage dient die Liste der N-Gramme. Für die aktuellen brauchen wir nur mono- und bigramme.
Kostenfaktor: Zeit
- Unterschiedlich schnell zu erreichende Tasten => Kosten für einzelne Tasten. - done
- Einen Finger mehrfach hintereinander verwenden. => Strafpunkte. - done
- Einen Finger mehrfach, von oben nach ganz unten. => viele Strafpunkte. - TODO
Kostenfaktor: Belastung
- Ungleichmäßige Belastung beider Hände. - TODO
- Ungleichmäßige Belastung der einzelnen Finger (allerdings sollte der Kleine weniger belastet werden). - TODO
Kostenfaktor: Natürliche Handbewegung
- Von innen nach außen mit Handwechsel. => von außen nach innen gibt Strafpunkte. - TODO
- Links gleicher Finger wie rechts. => Fingerwechsel bei Handwechsel hat Kosten. - TODO
Kostenfaktor: Neulernzeit
(die ideale Tastatur kann jeder schon - und wir optimieren für Neo)
- Jede einzelne Änderung von Neo2 weg bringt Strafpunkte => Es kann über Gewichtung festgelegt werden, wie nahe das Ergebnis an Neo liegen soll. - TODO
Zusatzinfos (für die Neo Liste)
Hi,
Ich habe in den letzten Wochen an meinem evolutionären Optimierungscode gebastelt und bin jetzt so weit, dass ich auf eine große Zahl Bedingungen prüfen kann.
Das Grundprinzip ist, jedem Tastendruck einen Kostenfaktor zuzuweisen, dazu weitere Kosten für Fingerwiederholungen u.ä.
Theoretisch kann ich einen Großteil der Bedingungen abbilden, die einzelne Buchstaben, Bigramme und/oder Trigramme nutzen und dann die Tastatur so lange zufällig variieren, bis die Kosten um einen Text zu schreiben minimal werden (inklusive Beginn mit zufälliger Tastatur). Bisher allerdings nur für Ebene 1 plus Großschreibung mit Shift (heißt auch, dass Sonderzeichen bisher einfach ignoriert werden).
Ich brauche allerdings sinnvolle Kostenfaktoren, sonst ist das ganze Modell sinnlos.
Aktuell sieht das Grundmodell der Tastatur so aus:
NEO_LAYOUT = [
]
( http://bitbucket.org/ArneBab/evolve-keyboard-layout/src/25da1c40e553/che... )
Dazu gibt es für jede Position der Finger fixe Kosten (pro Tastendruck):
COST_PER_KEY = [ # 0 heißt nicht beachtet
]
( http://bitbucket.org/ArneBab/evolve-keyboard-layout/src/25da1c40e553/che... )
D.h. Die Tasten unter dem Zeigefinger kosten 1 (keine Einheit), die Tasten unter Mittel und Ringfinger kosten 2 und die Tasten unter dem Kleinen Finger kosten 3, usw. - Tasten mit Kosten 0 sollte es nicht geben, allerdings wird jedes Zeichen mit Kosten 0 zur Zeit ignoriert ( genauer: Tasten die geändert werden: http://bitbucket.org/ArneBab/evolve-keyboard-layout/src/783b6489128f/che... ).
Zusätzlich kosten Fingerwiederholungen je 5 (zusätzlich zu den Kosten der Einzeltasten).
(wer sich daran stört, dass die Kosten keine Einheit haben, kann einfach uke nehmen: Unteilbare Kosteneinheit :) ).
Was ich jetzt brauche:
Wieviel soll welche Taste kosten? (Grundlage: 0 bedeutet, dass das Zeichen ohne Zeitaufwand und Belastung sofort im Rechner ist => theoretische telepathische Idealtastatur; die Minimalkosten pro Taste sind 1 (aus technischen Gründen). => Ich brauche einen Konsens darüber, wie COST_PER_KEY aussehen soll.
Wieviel soll eine Fingerwiederholung kosten (relativ zu den Kosten der Tasten)? „Was ist teurer, eine Fingerwiederholung oder zusätzlich mit dem kleinen Finger nach rechts oben greifen zu müssen?” => Welche Kosten pro Fingerwiederholung?
Was gibt es sonst an Kosten? (Beispiele: Zweimal die gleiche Hand verwenden. Bei drei Tasten mit der dritten Taste auf der gleichen Hand zu sein wie bei der ersten, aber weiter innen. … ) => Welche zusätzlichen Kostenfaktoren?
Prinzipiell können zusätzliche Kostenfaktoren so gefunden werden:
Was ist die ideale Art, die 2 oder 3 Tasten hintereinander zu drücken? Das kostet nur das, was die Tasten einzeln kosten (keine Zusatzkosten).
Welche anderen Arten gibt es, die Tasten zu drücken? Wie viel schlechter sind die als die ideale Art? Im Vergleich dazu, eine einzelne Taste zusätzlich zu drücken? => Kosten für diese Art die Tasten zu drücken.
Beispiel: - Ideal: Zwei Tasten hintereinander sollten auf unterschiedlichen Fingern liegen. - Kosten: Wenn sie auf dem gleichen Finger sind, kostet das 5 zusätzlich; soviel, als müsste ich mit einem Finger zusätzlich in die untere Reihe runter.
Und solche Kosten brauche ich zur Optimierung. Was das Programm nämlich (etwas vereinfacht) macht ist, die Kosten aller Zeichen, Bigramme und Trigramme aus den verschiedenen Faktoren zu addieren und dann zufällig Tasten zu vertauschen (zwei oder mehr) und danach zu schauen, ob die Kosten des neuen Layouts niedriger sind. Wenn ja wird es beibehalten und dann von der Basis aus weiter gemacht. Wenn nein wird die Änderung verworfen.
Also: Was gibt es an Kosten, auf die ein Layout optimiert sein sollte? (Ja, ich möchte dazu eine Diskussion lostreten - dadurch können wir die Anforderungen an eine Tastatur teilweise quantisieren.
Wenn ich das habe, kann ich sie integrieren und dann nach diesen Kosten optimierte Layouts rechnen lassen.
Da der Code evolutionär arbeitet, kommt am Ende kein einzig perfektes Layout heraus, sondern viele unterschiedlich stark optimierte, aus denen dann ein bestes ausgewählt werden kann. Was ich persönlich als Vorteil empfinde, weil alle Aussagekraft sowieso durch die Qualität der Kostenfaktoren bedingt wird. Da ist es ganz gut, dass das Programm gar nicht erst vorspiegelt, ein perfektes Ergebnis zu finden.
Zur Geschwindigkeit: Aktuell kann ich binnen eines Tages etwa 100 zufällige Tastaturlayouts so weit optimieren, dass eine Vertauschung von Tasten keinen weiteren Vorteil bringt, oder 100 mal Neo evolutionär entwickeln (mit mehr Kostenfaktoren vermutlich etwas weniger). Das Programm rechnet dabei auf meinem schon etwas älteren Rechner etwa einen Evolutionsschritt pro Sekunde; normalerweise ist ein Layout nach 100 Schritten recht stabil und nach 1000 tut sich selten noch was.
Liebe Grüße,
Arne
PS: Wenn ihr das Programm selbst ausprobieren wollt:
- http://bitbucket.org/ArneBab/evolve-keyboard-layout/
Direkter Download der aktuellen Version:
- http://bitbucket.org/ArneBab/evolve-keyboard-layout/get/tip.bz2
Oder über Mercurial ( http://mercurial.selenic.com ):
- hg clone https://ArneBab@bitbucket.org/ArneBab/evolve-keyboard-layout/
Da dann ./check_neo.py --help
Beispiel 1: Neo 100 Schritte weit evolutionär entwickeln: ./check_neo.py --evolve 100
Beispiel 2: Neo vs. Qwertz mit beliebigem Text: ./check_neo.py --file beispieltext-prosa.txt
Beispiel 3: Neo vs. Qwertz mit 1gramme.txt und 2gramme.txt ./check_neo.py
Beispiel 4: Zufälliges Layout 100 Schritte weit entwickeln ./check_neo.py --evolve 100 --prerandomize 100000
(damit das läuft braucht ihr außerdem Python 3.x -> http://python.org )
PPS: Ich tippe inzwischen fast nur noch mit Neo weil es sich einfach natürlicher anfühlt, auch wenn mir noch manchmal über mehr als ein Jahrzehnt eintrainierte Reflexe in die Quere kommen :)
PPPS: Wenn das Prog in ein lokales Minimum rutscht und Einzeländerungen nichts mehr bringen, geht es nach 100 erfolglosen Einzelersetzungen zu Zweifachersetzungen über, nach 1000 dann zu Dreifachersetzungen, …
P4S: Die Ausgabe des Evolutionsdurchgangs kann direkt wieder als neues Layout in der Datei genutzt werden. Mit "-q" werden Zwischenstatusinfos weggelassen (nützlich für Mehrfachausführung in einer Schleife, um nicht von der Ausgabe erschlagen zu werden).