Re: [Neo] xcvz links oder nicht?
Hallo Arne! Erstmal danke für Deine unermüdliche Arbeit! On 31.07.2010 23:59, Arne Babenhauserheide wrote: Brauchen wir xcvz zwingend links oder nicht? Kurz und gut: Nein. Wenn eine bessere Optimierung ohne xcvz-Fixage heraus kommt, ist diese auch vorzuziehen. Wer mit der weiten Verstreuung vor xcvz ein Problem hat, kann sich die entsprechenden Shortcuts immer noch auf M4+1/2/3/4 legen, das tippt sich im Zweifel genauso gut. – Mœsi
Re: [Neo] xcvz links oder nicht?
Karl Köckemann wrote: Die erforderlichen Griffe für Strg+(xcvz) sind sowieso ungünstig. Dass manche Tipper sich daran gewöhnt haben ändert doch nichts daran. Deswegen: Nein, für zwingend erforderlich halte ich xcvz links nicht. Dann schaue ich, ob sie die allgemeine Optimierung stören (nicht leicht zu definieren, weil die Streuung so hoch ist, aber wofür gibt es Versuchs-Auswertungen…). Falls ja (und falls niemand veto einlegt), fliegen sie raus. Nebenbei: An der Hardware arbeite ich hin und wieder weiter. Cool! Für unsere Anforderungen brauchen wir unbedingt mindestens eine Fn-Taste. Genau die habe ich mit dem Keyboard-Encoder-Chip SK5101 bislang nicht zum Funktionieren bringen können, trotzdem sich die Tastenbelegung schon einmal beliebig belegen läßt. Heißt das, du bekommst bereits eine vollständige Neo-Tastatur hin? Liebe Grüße, Arne
Re: [Neo] xcvz links oder nicht?
Hi Matthias, Matthias Wächter wrote: Erstmal danke für Deine unermüdliche Arbeit! Es hat mich halt gepackt ;) Und es ist auch schön zu wissen, dass das, was ich mache, auch für andere sinnvoll ist. On 31.07.2010 23:59, Arne Babenhauserheide wrote: Brauchen wir xcvz zwingend links oder nicht? Kurz und gut: Nein. Wenn eine bessere Optimierung ohne xcvz-Fixage heraus kommt, ist diese auch vorzuziehen. OK. Ich lasse gerade Layouts mit xcvz links erzeugen. Nächste Runde ist dann ein Vergleich ohne. Liebe Grüße, Arne
Re: [Neo] xcvz links oder nicht?
Michael Ostermeier wrote: Die Evolution braucht also ziemlich viele Durchläufe. Performanz kann also möglicherweise wichtiger werden. Die Evolution kommt meist nach etwa 3000 Durchläufen bei einem lokalen Minimum an, das sich auch nicht mehr ändert. Deswegen bringt jede Komplett-Evolution ein anderes Ergebnis. Inzwischen mache ich es so, dass erst 3000 zufällige Mutationsschritte kommen und dann so lange die jeweils beste Veränderung, bis es nichts mehr zu verbessern gibt. Meist ist die Tastatur aber nach den 3000 Schritten schon optimal. Die Leistung ist dadurch eher zweitrangig. Ich brauche über eine Stunde pro Layout, aber das kann gut im Hintergrund laufen (minimaler Ramverbrauch). Was ich prinzipiell interessant fände, wäre mir mal einen Überblick über die verschiedenen Ergebnisse zu verschaffen und zu schauen, ob es Regelmäßigkeiten gibt. Ich vermute nämlich verschiedene Grundtypen von Tastenanordnungen. Vielleicht ist es am einfachsten, einmal auf ‚alle links‘ zu optimieren, danach auf ‚egal‘ und zu schauen, wie groß denn der Unterschied ist, um sich auf eines festzulegen. Oder kannst Du den Unterschied schon beziffern? Noch kann ich ihn nicht beziffern. Aber ich kann mal ein paar Durchläufe machen. Dauert halt etwas :) Vorher mache ich allerdings noch ein paar Durchläufe mit doppelten Tastenkosten. Liebe Grüße, Arne
Re: [Neo] xcvz links oder nicht?
Michael Ostermeier wrote: Also, mir ist folgendes (unangenehm) Aufgefallen: ävu Mi (Be ist etwas besser) Kr (wahrscheinlich nicht auf Andere übertragbar) Kommt mir das nur so vor, oder ist das ä etwas häufig? … ah, das ist das A! Die Position finde ich doch ein bisschen erstaunlich. Kann sein, dass ich die Gewichtung der Tastenpositionen noch etwas hochschrauben muss… Ich schau mal, was passiert, wenn ich ihre Gewichtung verdopple. ä für a ist dann nämlich doch etwas heftig – die Position bringt mehr als dreimal so hohe Kosten (10 statt 3). An dieser Stelle wären jetzt die key position costs von Nordtast interessant. Stimmt die vom 06. Mai (e1oa1mn-0006x3...@smtp06.web.de) noch immer?: # 3.88135283731 mean key position cost in file 1gramme.txt hier: # 4.14265459331 mean key position cost in file 1gramme.txt Nicht mehr ganz. Mit der aktuellen COST_PER_KEY kommt Nordtast auf # 3.91283155644 mean key position cost in file 1gramme.txt Das sind damit knapp 5.9% mehr. Ob das viel ist, kann ich nicht genau beziffern. Aber die bisherigen Tests ergeben, dass die Tastenpositionen der wichtigste Parameter sind, danach die Fingerwiederholungen. Also dürfen die Tastenpositionen nicht zu schlecht werden. Gleichzeitig sind übrigens die Fingerwiederholungen nochmal niedriger als bei NordTast: NordTast: 1.52532968344 % finger repeats in file 2gramme.txt Aktuell bestes: # 1.33678692555 % finger repeats in file 2gramme.txt Ach ja, und weil wir schon bei „Wünsch dir was“ sind ;-) : Könnte man eigentlich für die Bewertungspunkte auch die Punktzahl ausgeben lassen, wie sie dann tatsächlich zur Gesamtpunktzahl addiert werden? Dann könnte man leicht sehen, was wieviel Einfluss hatte. Habe ich jetzt gemacht :) Und dabei habe ich gerade bemerkt, dass die Kostenberechnung für xcvz schlicht nicht funktionieriert hat, daher waren die Ergebnisse dazu einfach nur Zufall :) (es hat immer das Neo Layout genutzt, statt die Tasten beim mutierten zu suchen). Ist jetzt korrigiert. # 0.00492235411659 hand disbalance. Left: 0.495077645883 %, Right: 0.504922354117 % Krass! ;-) Die Testergebnisse mit Texten haben gezeigt, dass sich eine Disbalance der Finger recht stark auswikt, deswegen habe ich die Gewichtung erhöht :) Das krasseste dazu ist das hier (jetzt auch mit den Gewichteten Werten, allerdings auch ein paar config Änderungen (total penalty nicht mehr vergleichbar)): jüäo, xlmhkp´ teciu grnsdz yqa.ö vwbfß # 4.06715353344 billion total penalty compared to notime-noeffort # 4.21185720717 mean key position cost in file 1gramme.txt ( 2.425222372 ) # 1.67910498535 % finger repeats in file 2gramme.txt ( 0.179666272 ) # 3.26745422852 million keystrokes disbalance of the fingers ( 0.196047253 ) # 0.0662257906224 % finger repeats top to bottom or vice versa (0.01417248) # 20.8438818898 % of trigrams have no handswitching ( 0.080923861 ) # 0.220342970241 billion (rows/dist)² to cross ( 0.220342970241 ) # 0.000484818860896 hand disbalance. Left: 0.499515181139 %, Right: 0.500484818861 % # ( 0.5182274772 badly positioned shortcut keys (weighted).) # ( 0.2577 no handswitching after unbalancing key (weighted).) # ( 1.74850848 movement pattern cost (weighted).) Liebe Grüße, Arne
Re: [Neo] xcvz links oder nicht?
Arne Babenhauserheide writes: Brauchen wir xcvz zwingend links oder nicht? Die erforderlichen Griffe für Strg+(xcvz) sind sowieso ungünstig. Dass manche Tipper sich daran gewöhnt haben ändert doch nichts daran. Deswegen: Nein, für zwingend erforderlich halte ich xcvz links nicht. Nebenbei: An der Hardware arbeite ich hin und wieder weiter. Für unsere Anforderungen brauchen wir unbedingt mindestens eine Fn-Taste. Genau die habe ich mit dem Keyboard-Encoder-Chip SK5101 bislang nicht zum Funktionieren bringen können, trotzdem sich die Tastenbelegung schon einmal beliebig belegen läßt. Mit netten Grüßen Karl
Re: [Neo] xcvz links oder nicht?
Hallo, Ich bin weiterhin am Layouts basteln Schön zu hören. :-) und merke mehr und mehr, dass xcvz links oder nicht eine binäre Entscheidung ist: Wenn ich es in den Optimierer packe, verzerrt es die Ergebnisse. Selbst diejenigen, die am Ende nicht xcvz links haben, werden davon beeinflusst. Daher sollte der Parameter entweder so stark sein, dass xcvz auf jeden Fall links sind, oder komplett weggelassen werden. Mit meinen bescheidenen Softwarekenntnissen und deiner Aussage vom 29. April (e1o7zzx-7m...@smtp05.web.de): Ich habe die Kosten der Grundtasten von 1 auf 3 erhöht, vergebe aber pro schlecht positioniertem xcvz nur 0.1 Strafpunkte (also maximal 0.4) pro Zeichen im Text. denke ich herauszulesen, dass Du, während Du den Korpus auswertest, bei jedem xcvz, das im Korpus vorkommt, die Position der Taste prüfst. Stimmt das? Ich bin jetzt zu faul, da selbst nachzusehen (u.A. weil ich kein Python kann). Falls ja, finde ich nicht, dass das nötig ist. Der Code würde dann performanter, wenn nach der Prüfung des gesamten Korpus nur genau einmal die Position der vier genannten Tasten getestet würde. Dann gibt’s zwei Möglichkeiten. Entweder eine Strafpunktzahl vergeben, wenn eine oder mehr rechts liegen, um vollkommen binär zu werden. Oder diese Strafpunkte durch vier teilen und pro Taste vergeben. Im binären Fall könnte man durch geschickte Wahl der Strafpunktzahl erreichen, dass circa die Hälfte der Ergebnislayouts die Tasten links haben, die Andere optimal verteilt. Diese Strafpunktzahl sagt dann gleichzeitig aus, wie viel schlechter ein Xcvz-links-Layout durchschnittlich ist (umrechenbar in %). Die Auswirkungen auf die Nicht-alle-links-Layouts sollten dann m.E. eher gering sein. Brauchen wir xcvz zwingend links oder nicht? Da will ich mich jetzt noch nicht festlegen. ;-) Gruß Miche
Re: [Neo] xcvz links oder nicht?
Hallo Arne, denke ich herauszulesen, dass Du, während Du den Korpus auswertest, bei jedem xcvz, das im Korpus vorkommt, die Position der Taste prüfst. Stimmt das? Ich schauen einfach nur einmal pro Mutation, wo sie liegen. Ok, ich bin beruhigt. Möglichkeiten. Entweder eine Strafpunktzahl vergeben, wenn eine oder mehr rechts liegen, um vollkommen binär zu werden. Oder diese Strafpunkte durch vier teilen und pro Taste vergeben. Aktuell mache ich das letztere. Ich kann allerdings problemlos auf das erstere wechseln. Es klingt mir akut sinnvoller. Die Schwierigkeit liegt aber darin, dass durch den Malus jeder einzelne Mutationsschritt beeinflusst wird. Es kann sein, dass eine Veränderung nur deswegen nicht sinnvoll ist, weil einer von xcvz dadurch auf eine schlechte Position kommt, dann aber ein weiterer Schritt sie doch auf eine schlechte Position bringt, so dass sie am Ende nicht links sind, aber eine positive Veränderung fehlt. Das kann ich mir gut vorstellen. Wenn die Strafpunktzahl hoch ist, ist die Hürde für den Übergäng ‚alle links‘ nach ‚eins oder mehr rechts‘ vielleicht so hoch, dass erst Zwei- oder Dreifachersetzungen zum Ziel führen. Allerdings ist dann die Trefferwahrscheinlichkeit auch geringer, weil es schlicht zu viele mögliche Kombinationen gibt. Setzt man dann aber die Strafpunktzahl zu weit herunter, so kann es sein, dass fast nur noch ‚eins oder mehr rechts‘-Layouts rauskommen, weil der Anreiz, alles nach links zu schieben zu gering ist, was ja auch eher ein Zufallstreffer sein wird dann. Die Evolution braucht also ziemlich viele Durchläufe. Performanz kann also möglicherweise wichtiger werden. Es käme halt auf einen Versuch an. Falls nicht, so könnte die Lösung aber eine Mischform sein, die einerseits den Übergang erleichtert und andererseits weniger Seiteneffekte hat. Vielleicht ist es am einfachsten, einmal auf ‚alle links‘ zu optimieren, danach auf ‚egal‘ und zu schauen, wie groß denn der Unterschied ist, um sich auf eines festzulegen. Oder kannst Du den Unterschied schon beziffern? Gruß Miche
