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
<tab><tab>ret<tab> 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 knife.
Two policemen are there it once. They raise a sign:
“Illegal Scene! Noone may watch this!”
The man gets robbed and stabbed and bleeds to death.
The police had to hold the sign.
…Welcome to Europe, citizen. Censorship is beautiful.
( http://draketo.de/stichwort/censorship )
signature.asc
Description: This is a digitally signed message part.
