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 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?
Jupp, danke!
Das Zeichen stimmt, nur der Name nicht :)
> 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.
Ok, dann passt das soweit. Danke!
Das irreguläre Tippen von M4L habe ich mal als TODO eingefügt, auch wenn es
nicht ganz einfach zu korrigieren sein 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.
Dann wird der Code auch so gut wie nicht aufgerufen und tut entsprechend nicht
sehr weh.
In den Bigrammen tut eine zusätzliche if-Abfrage nicht sehr weh. In den
Trigrammen wäre das etwas anderes… :)
Liebe Grüße,
Arne
signature.asc
Description: This is a digitally signed message part.
