Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
Am 07.01.2010 18:49, schrieb wettstein...@solnet.ch: > Mit Ulfs Kriterium > kommt man grob gepeilt auf eine viertel Million Nebenbedingungen. Ist > das viel? Prinzipiell schon, aber ich traue mir da noch keine Einschätzung zu, ob das die Lösbarkeit beeinträchtigt. Es ist auch zu beachten, dass, wenn man beispielsweise nur n Buchstaben anordnet, lediglich n²·32² Nebenbedingungen entstehen (wegfallende nicht rausgerechnet). > Wenn man in der Testphase nur Fingerkollisionen > berücksichtigt bringt man die Anzahl der Bedingungen noch weiter runter. Naja, das bringt glaube ich nicht viel, weil man dann wahrscheinlich unheimlich viele Handkollisionen hat. Meine Erfahrung mit MIP-Modellen ist, dass man lieber von Anfang an alles reintut und dann schaut, wo vereinfacht werden kann, ansonsten fliegt einem mit der letzten Nebenbedingung oft das ganze Modell um die Ohren und man hat viel Zeit verloren. Ich werde mal zusehen, am Wochenende die Implementation abzuschließen. Viele Grüße Sepp (: smime.p7s Description: S/MIME Cryptographic Signature
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> z(ij) ≥ a(ij)c(tu)·(z(it)+z(ju)-1) ∀ i∈I, j∈I, t∈T, u∈T > > Diese Nebenbedingung ist tatsächlich ein wenig groß, auch wenn ein recht > hoher Teil schon rausfällt, da, wenn t und u sich auf beide Hände > verteilen, c(tu) ja 0 sein müsste. Das ist natürlich viel besser als mein Vorschlag. Mit Ulfs Kriterium kommt man grob gepeilt auf eine viertel Million Nebenbedingungen. Ist das viel? Wenn man in der Testphase nur Fingerkollisionen berücksichtigt bringt man die Anzahl der Bedingungen noch weiter runter. Andreas
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> Negatives in der Klammer macht aber nichts, da für jede > Buchstabenkombination mindestens einmal die Klammer positiv wird (jeder > Buchstabe muss einer Taste zugewiesen werden), und z(ij) mindestens > diesen Wert erreichen muss Bei n Tasten und Zeichen ist in den n² Termen in der Summe in (7) bei (n-1)² Termen die Klammer -1, bei 2n-1 Null, und bei einem Eins (natürlich vorausgesetzt die x erfüllen ihre Nebenbedingung). Die rechte Seite von (7) wird (wenn wir exotische Bewertungschemata beiseite lassen) also negativ sein. Zusammen mit (1) und (12) ist dann im Optimum z(ij) = 0. Oder? Meinem Verständis nach richtig wäre es, (12) zu streichen, dafür aus (7) eine Gleichung zu machen und die Klammer durch Größen b zu ersetzen für die gilt: b(itju) ≥ x(it)+x(ju)-1 b(itju) ≥ 0 Für n = 32 sind das mehr als zwei Millionen Nebenbedingungen. Andreas
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
Moin, > > Ein solches Modell spuckt am Ende idealerweise nur eine Tastatur aus, > > und das ist die den gegebenen Bedingungen entsprechend beste. > > …träum weiter… Es geht nur darum, dass das Ergebnis (sofern das Modell lösbar ist) das den gegebenen Bedingungen entsprechend beste ist, es also maximal gleichwertige geben kann. Dies bezieht sich allerdings einzig und allein auf die gegebenen Kostenwerte und nichts anderes. Sepp (: smime.p7s Description: S/MIME cryptographic signature
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
Hallo allerseits, Pascal Hauck ſchrieb am 06.01.2010 10:20 Uhr: Am Mittwoch, 6. Januar 2010 01:17:18 schrieb Sebastian Werk: meinetwegen könnte die Ziffernreihe auch komplett mit Sonderzeichen vollgestopft werden, aber das geht dann wohl doch zu weit… Nicht unbedingt. Nein, ich habe bei mir jetzt schon länger die ersten beiden Ebenen der Zahlenreihe dauerhaft vertauscht und finde es sehr angenehm, jetzt »«$€„“” direkt tippen zu können – die Ziffern gebe ich sowieso ausſchließlich über die 4. Ebene ein. Die Umstellung ging ziemlich schnell, nur an das weggefallene ˆ1=¹, ˆ2=², ˆ3=³ auf der ersten Ebene musste ich mich gewöhnen. Seitdem tippe ich dafür Mod3+123 und Compose (♫^6=⁶) für die höheren Zahlen (wenn man sie denn wirklich mal braucht). Ich spiele momentan mit dem Gedanken, eine Schalter nur für die 10 Ziffern des Hauptfeldes zu verwenden, so dass auf der Ebene 1 situativ Ziffern oder Sonderzeichen getippt werden können. Quasi eine Art NumLock. Eine gute Idee, auch wenn ich persönlich es schöner fände, wenn Neo konsequent auf den Mod-4-Ziffernblock setzen würde. Man könnte weiter überlegen, die toten Zeichen nicht auf drei Tasten zu konzentrieren, wodurch sie schwer erzeugbar werden, sondern auf die Ziffern‑Tasten 1 bis 6 zu verteilen. Auch eine interessante Idee! Das müsste man mal in der Praxis ausprobieren. Viele Grüße, Dennis-ſ
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
Hallo allerseits, Sebastian Werk ſchrieb am 05.01.2010 20:21 Uhr: ein gemischt-ganzzahliges lineares Optimierungsmodell für die automatische Optimierung Sehr schön, Sebastian! Wie Du selbst schon geschrieben hast, würde uns ein LP-Modell den großen Vorteil bringen, dass wir zum ›Lösen‹ kampferprobte Standardprogramme nutzen können und hier nicht mehr das Rad neu erfinden müssten. Sehr schön! Das Modell ist weitestgehend fertiggestellt, Die PDF ist gut und schön, aber der TeX-Quellcode wäre auch nicht zu verachten (Autsch, Zaunpfahl ;-)) Viele Grüße, Dennis-ſ
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
Am Mittwoch, 6. Januar 2010 01:17:18 schrieb Sebastian Werk: > meinetwegen könnte die Ziffernreihe auch komplett mit > Sonderzeichen vollgestopft werden, aber das geht dann wohl doch zu weit… Nicht unbedingt. Ich spiele momentan mit dem Gedanken, eine Schalter nur für die 10 Ziffern des Hauptfeldes zu verwenden, so dass auf der Ebene 1 situativ Ziffern oder Sonderzeichen getippt werden können. Quasi eine Art NumLock. Auf diese Weise wären Sonderzeichen, die ausschließlich in Texten verwendet werden (Anführungszeichen, Bindestrich, …), besser erreichbar (Textmodus), ohne dass gänzlich auf die Ziffernreihe (Zahlenmodus) verzichtet werden muss. Da ein gleichzeitiger Gebrauch unwahrscheinlich ist¹, kommt es kaum zu Kollisionen. Man könnte weiter überlegen, die toten Zeichen nicht auf drei Tasten zu konzentrieren, wodurch sie schwer erzeugbar werden, sondern auf die Ziffern‑Tasten 1 bis 6 zu verteilen. Statt 3⋅6 erhielte man 6⋅3 tote Zeichen, für die immer nur ein Modifier benötigt wird. In den Ebenen 4 bis 6 würden keine Plätze für tote Zeichen mehr benötigt, es können andere Zeichen aufgenommen werden und die Modularisierung fällt leichter. Im Zahlenmodus gewönne man Platz, um wichtige Nicht‑ASCII‑Zeichen wie ⋅ ± ≈ auch auf Tastaturen ohne Keypad anzubieten. Bislang alles nur graue Theorie, aber interessant genug, um es im Rahmen von Neo3 zu erproben und auf Alltagstauglichkeit zu prüfen. Gruß, Pascal ¹ meist tippt man entweder Text oder Zahlen; außerdem steht noch die Ebene 4 zur Verfügung signature.asc Description: This is a digitally signed message part.
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> Warum keine Bestrafung für Einwärtsbewegungen? War es bei Neo2 nicht so, > dass Auswärtsbewegungen für besser als Einwärtsbewegungen gehalten > wurden wegen Abrollen? Richtig. Du kannst es ja machen, wie du willst. Ich sage ganz klar: Neo hat Unrecht. Aber du kannst ja beides machen, mal so, mal so. > Hmm, ich finde, der Zeigefinger ist der trainierteste Finger von allen, > von daher würde ich da nicht nach Fingerlänge gehen, aber das sollte > sicher eingehend diskutiert werden. Ich nehme an, dass grundsätzlich ALLES auf der Neo-Liste eingehend diskutiert werden muss. Je länger, desto besser. Wenn du die Tastaturen für Zeigefinger maximierst, solche habe ich auch gemacht, dann legst du gute Buchstaben auf die Streckbewegungen der Zeigefinger, die dann häufig werden. Ich habe gute Erfahrungen mit Q und anderen seltenen Zeichen auf dem Zeigefinger. Ist meine Meinung. > Ein solches Modell spuckt am Ende idealerweise nur eine Tastatur aus, > und das ist die den gegebenen Bedingungen entsprechend beste. …träum weiter… > Es ist > eben ein Optimierungsverfahren und keine Verbesserungsheuristik wie die > Nachbarschafts- oder Tabusuche, die bisher, soweit ich das verfolgt > habe, implementiert wurde. Na dann, zeig mal, was du kannst. Spätestens wenn die Neo-Leute es in die Finger kriegen, wird das in Kleinteile zerrissen. Etwas technisch Gutes zu machen ist kein Problem. Es akzeptiert zu bekommen ist etwas gänzlich anderes. Viel Spaß! Nein, im Ernst. Versuche mal. Wir müssen ja weiter. Irgendwie. Ulf
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> > Interessant finde ich Gleichung (3). Kann man diese Bedingung > > verallgemeinern? Man stelle sich vor, eine Tastatur mit zwei e's, von > > denen man jeweils das bequemere tippt? > Das ist in der Form nicht vorgesehen, das würde auch einige andere > Nebenbedingungen ziemlich stark beeinträchtigen. Man kann solche Alternativen wohl sowieso nicht alleine mit Bigrammhäufigkeiten richtig modellieren. Ist auch nicht so wichtig, es wäre vemutlich auch zu schwer zu lernen. Andreas
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
Am Mittwoch, den 06.01.2010, 00:36 +0100 schrieb Ulf Bro: > > Wiederholung (gibt es andere Kosten bei Sprung von Grundlinie nach oben > > als von unterer Linie nach oben usw.) > > Den hatte ich vergessen. Fingerwiederholung habe ich als solches nur so > gezählt. Aber nachher, beim Betrachten der „tatsächlichen > Schreibtätigkeit“ habe ich Wohlwollen empfunden, wenn die Wiederholung > von oben nach unten geht. Von unten nach oben ist leicht lästig. Der > Zeigefinger kann ganz dumme Sprünge machen. Bewertet habe ich das nicht. > Soll man? Implementierbar wären solche Sachen problemlos, letzlich muss jeder Sprung von einer Taste zu einer beliebigen anderen irgendwie bewertet werden. Solange es nachvollziehbar bleibt, ist eine feinere Staffelung umso besser. Eine Anmerkung noch zur Position des Kommas: Ich persönlich bin absolut dagegen, dass die Ziffernreihe auch nur irgendwie bei der Anordnung berücksichtigt wird, zur Zifferneingabe ist meiner Meinung nach die vierte Ebene da, meinetwegen könnte die Ziffernreihe auch komplett mit Sonderzeichen vollgestopft werden, aber das geht dann wohl doch zu weit… Viele Grüße Sepp (: smime.p7s Description: S/MIME cryptographic signature
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
Hallo, > > • Kosten für die einzelnen Tasten > > Pascal behauptet, dass er eine demokratisch gewählte Liste hat. Meine > war bisher: > > 5 3 3 3 4 4 3 3 3 5 7 > 1 0 0 0 2 2 0 0 0 1 7 > 6 5 5 5 7 7 5 5 5 6 > Ich würde es bevorzugen, wenn jede Position einer Hand zumindest geringfügig unterschiedliche Werte hat. Die Werte müssen ja nicht unbedingt ganzzahlig sein. > > • Kosten für Fingerwiederholung bei Bigramm in Abhängigkeit der Art der > > Wiederholung (gibt es andere Kosten bei Sprung von Grundlinie nach oben > > als von unterer Linie nach oben usw.) > > • gleiches für Einwärts- und Auswärtsbewegung > > > > Ich bin so vorgegangen: > > 1. Lagepunkte: > > Mache eine Liste aller Buchstabenhäufigkeiten (auf meiner Homepage ist > eine) in __Prozent__ (summiert sich zu 100.00 bei Addition). Bei jedem > Anschlag wird diese Zahl mit der Platzzahl von oben multipliziert. Das > ganze wird summiert und mit der Gesamtzahl der Buchstaben geteilt. Hätte > jede Taste „1“ Lagepunkt, wäre das Endergebnis 100. Mit der obigen > Punkteverteilung hat eine gute Tastatur 145-155 LagePunkte. Gut, das ist schon mal ein guter Richtwert. > 2. Bigramme: > > Ein Bigramm kann 4 Richtungen einschlagen: Finger wiederholen, Finger > einwärts, Finger auswärts, Andere Hand. Die Summe dieser Prozente sollte > 100.00 sein. Ich vergebe beispielsweise: > > (200 * Fingerwiederholung) + (2 * Auswärts) > > als Auswertung der Bigramme. Macht bei einer guten Tastatur 120 + 8 = > 128 Bigrammpunkte oder so. Warum keine Bestrafung für Einwärtsbewegungen? War es bei Neo2 nicht so, dass Auswärtsbewegungen für besser als Einwärtsbewegungen gehalten wurden wegen Abrollen? > > • Kosten für Shift (ist das gleichwertig zu untere Reihe kleiner Finger > > oder wird es etwas niedriger bewertet) > > Ich würde wie der Kollege eine Optimierung mit Shift-Bewertung machen > (keine Ahnung, wie das geht) und eine ohne. Das wäre dann mal interessant zu erfahren, da muss ich eh noch sehen, wie ich das umsetze, möglich ist es definitiv. > > • Kosten für Über- oder Unterschreitung der vorgesehenen > > Anschlagshäufigkeit der Finger > > Ja. Das ist ein Problem. Da haben wir ein bisschen gebastelt. Da bin ich > mir nicht sicher, wie das sein soll. Ich glaube, dass man eine > Häufigkeit haben soll, die wie die Länge der Finger ist (zufällig?), > also Mittelfinger viel, Zeige- und Ringfinger weniger, Kleinfinger noch > weniger. Ist meine Meinung. Hmm, ich finde, der Zeigefinger ist der trainierteste Finger von allen, von daher würde ich da nicht nach Fingerlänge gehen, aber das sollte sicher eingehend diskutiert werden. > > • Kosten für maximale Abweichung von vorgesehener Anschlagshäufigkeit > > der Finger > > Kein Vorschlag meinerseits. Ich habe viel nachgedacht, aber weiß es > nicht. > > > • Kosten für Abweichung von 50 Prozent der Aufteilung der Hände > > Nicht sehr wichtig. Wenige Punkte. Wenn du viele Tastaturen machst, > können wir die schiefsten nachher wegschmeißen. (?) Ein solches Modell spuckt am Ende idealerweise nur eine Tastatur aus, und das ist die den gegebenen Bedingungen entsprechend beste. Es ist eben ein Optimierungsverfahren und keine Verbesserungsheuristik wie die Nachbarschafts- oder Tabusuche, die bisher, soweit ich das verfolgt habe, implementiert wurde. > > Ich bin jetzt beim Zusammenstellen der Parameter, und dann werde ich das > > mal umsetzen und schauen, ob es noch mit Standardoptimierungssoftware > > lösbar ist. Ansonsten ist auch denkbar, sequenziell vorzugehen, also > > beispielsweise zuerst die wichtigsten zwölf Tasten zu fixieren und dann > > die weiteren. > > Ja. Das hast du ja schon mal gesagt. Auch das habe ich viel nachgedacht. Moment, das letzte Mal, als ich ein solches Verfahren vorgeschlagen hatte, handelte es sich um eine Brute-Force-Attacke, das ist so ziemlich das Gegenteil von dem Optimierungsmodell. Nichtsdestotrotz ist es denkbar, auch dem Modell Einschränkungen zu geben, aber da warte ich erstmal die ersten Tests ab. Meine Befürchtung ist, dass das Modell zwar eine sehr gute Lösung finden wird, aber eventuell nicht der Nachweis geführt werden kann, dass es die beste ist (oft ist es schwierig, eine starke untere Schranke zu finden). Ein solches Ergebnis wäre dann aber eine prima obere Schranke für eine Brute-Force-Attacke, bei der dann auf andere Art nach der besten Lösung gesucht wird. Diese Vorgehensweise würde eventuell die Zusatzeinschränkungen obsolet machen. Viele Grüße Sepp (: smime.p7s Description: S/MIME cryptographic signature
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
Hallo, > Auf der rechten Seite von (7) müssen x'e statt z's stehen, für die z's > passen die Indices nicht. Richtig, Fehler meinerseits > Zudem kann in der Klammer etwas negatives > stehen; ist das ein Problem? Sollte man nicht ein Produkt zweier x'e > statt z+z-1 (bzw. x+x-1) haben, oder ist das dann nicht mehr > gemischt-ganzzahlig linear? Das wäre genau das Problem bei Multiplikation. Negatives in der Klammer macht aber nichts, da für jede Buchstabenkombination mindestens einmal die Klammer positiv wird (jeder Buchstabe muss einer Taste zugewiesen werden), und z(ij) mindestens diesen Wert erreichen muss. Die Variante Z>=(x+y-1)·Wert ist die übliche Art und Weise in solchen Modellen UND-Bedingungen zu modellieren. > Interessant finde ich Gleichung (3). Kann man diese Bedingung > verallgemeinern? Man stelle sich vor, eine Tastatur mit zwei e's, von > denen man jeweils das bequemere tippt? Das ist in der Form nicht vorgesehen, das würde auch einige andere Nebenbedingungen ziemlich stark beeinträchtigen. Danke für Deine Anmerkungen Sepp (: smime.p7s Description: S/MIME cryptographic signature
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> Wiederholung (gibt es andere Kosten bei Sprung von Grundlinie nach oben > als von unterer Linie nach oben usw.) Den hatte ich vergessen. Fingerwiederholung habe ich als solches nur so gezählt. Aber nachher, beim Betrachten der „tatsächlichen Schreibtätigkeit“ habe ich Wohlwollen empfunden, wenn die Wiederholung von oben nach unten geht. Von unten nach oben ist leicht lästig. Der Zeigefinger kann ganz dumme Sprünge machen. Bewertet habe ich das nicht. Soll man? Dann haben wir noch sonstige „große Sprünge“: Also, Sprünge von ganz oben nach ganz unten sind ja nicht immer böse. Wenn es vom Zeigefinger auf den Kleinfinger ist, ist es ja egal. Ist es aber vom linken Ringfinger unten auf linken Mittelfinger oben, dann ist es übelst („EXE“ auf Qwerz). Rechts geht es wegen der Schräglage schlecht vom rechten Ringfinger oben auf rechten Mittelfinger unten („o,“ auf Qwerz). Und ähnlich. Nicht so einfach zu programmieren, Filigranarbeit und Gefummels. Ob es was bringt, wird man ja sehen. Kannst du dir ja auch für später aufheben. Ulf
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> Da ich jetzt mal wieder etwas mehr Zeit habe, hab’ ich mich daran > gemacht, ein gemischt-ganzzahliges lineares Optimierungsmodell für die > automatische Optimierung zu entwerfen. Ein solches Modell hat den > Vorteil, dass leistungsfähige Standardoptimierungssoftware existiert, > mit der oft eine optimale (oder zumindest sehr gute) Lösung hinsichtlich > der Bewertungskriterien gefunden werden kann. Unglaublich! Ich verstehe keinen Seufzer, aber es hört sich gut an. > Abweichung von der vorgesehenen Belastung zu evaluieren.¹ Auch Bigramme > in der momentanen Form stellen kein Problem dar, gleiches gilt > voraussichtlich für Trigramme (die wurden in den bisherigen Ansätzen, > soweit ich das gesehen habe, noch gar nicht berücksichtigt). Einzig > quadratisch eingehende Bewertungskriterien sind bei linearen Modellen > naturgemäß nicht möglich und die Shift-Taste ist noch nicht integriert. Ich würde die Trigramme zunächst ignorieren. Wenn du einige (oder nur eine) gute Tastaturbelegungen entworfen hast, ist es interessanter, sich anhand dieser Belegung die „tatsächliche Schreibtätigkeit“ anzuschauen. Ich habe meine Homepage http://bro.homepage.t-online.de/ noch nicht geupdatet, und das, was darauf steht, ist noch mit den alten fehlerhaften Bigrammtabellen ausgerechnet. Blättere aber herunter bis „Analyse der tatsächlichen Schreibtätigkeit“. Da siehst du, was der Schreiber letztendlich mit der Tastatur macht. Im vorliegenden Fall stimmen die Zahlen. Da kannst du die Listen durchgehen und dann selber entscheiden, ob die Fingerbewegungen, von denen dort die Rede ist, annehmbar sind oder nicht. Diese Analyse ist eine Art Postprocessing und stellt aber auch so etwas wie eine „Fazitliste“ dar. Das kann man machen, nachdem man fertig ist. Da kommen tatsächlich getippte Trigramme und all sowas vor. Im Sinne der Optimierung selber gewinnt man (glaube ich…) nichts durch Anwendung von Tri-, Tetra-, oder anderen Polygrammen außer Bigrammen. Ist meine Meinung. > Das Modell ist weitestgehend fertiggestellt, allerdings bräuchte ich > jetzt die genauen Bewertungskriterien (also Kosten) für die einzelnen > Punkte. Ich schreibe mal kurz zusammen, was mir so fehlt: > > • Kosten für die einzelnen Tasten Pascal behauptet, dass er eine demokratisch gewählte Liste hat. Meine war bisher: 5 3 3 3 4 4 3 3 3 5 7 1 0 0 0 2 2 0 0 0 1 7 6 5 5 5 7 7 5 5 5 6 > • Kosten für Fingerwiederholung bei Bigramm in Abhängigkeit der Art der > Wiederholung (gibt es andere Kosten bei Sprung von Grundlinie nach oben > als von unterer Linie nach oben usw.) > • gleiches für Einwärts- und Auswärtsbewegung > Ich bin so vorgegangen: 1. Lagepunkte: Mache eine Liste aller Buchstabenhäufigkeiten (auf meiner Homepage ist eine) in __Prozent__ (summiert sich zu 100.00 bei Addition). Bei jedem Anschlag wird diese Zahl mit der Platzzahl von oben multipliziert. Das ganze wird summiert und mit der Gesamtzahl der Buchstaben geteilt. Hätte jede Taste „1“ Lagepunkt, wäre das Endergebnis 100. Mit der obigen Punkteverteilung hat eine gute Tastatur 145-155 LagePunkte. 2. Bigramme: Ein Bigramm kann 4 Richtungen einschlagen: Finger wiederholen, Finger einwärts, Finger auswärts, Andere Hand. Die Summe dieser Prozente sollte 100.00 sein. Ich vergebe beispielsweise: (200 * Fingerwiederholung) + (2 * Auswärts) als Auswertung der Bigramme. Macht bei einer guten Tastatur 120 + 8 = 128 Bigrammpunkte oder so. > • Kosten für Shift (ist das gleichwertig zu untere Reihe kleiner Finger > oder wird es etwas niedriger bewertet) Ich würde wie der Kollege eine Optimierung mit Shift-Bewertung machen (keine Ahnung, wie das geht) und eine ohne. > • Kosten für Über- oder Unterschreitung der vorgesehenen > Anschlagshäufigkeit der Finger Ja. Das ist ein Problem. Da haben wir ein bisschen gebastelt. Da bin ich mir nicht sicher, wie das sein soll. Ich glaube, dass man eine Häufigkeit haben soll, die wie die Länge der Finger ist (zufällig?), also Mittelfinger viel, Zeige- und Ringfinger weniger, Kleinfinger noch weniger. Ist meine Meinung. > • Kosten für maximale Abweichung von vorgesehener Anschlagshäufigkeit > der Finger Kein Vorschlag meinerseits. Ich habe viel nachgedacht, aber weiß es nicht. > • Kosten für Abweichung von 50 Prozent der Aufteilung der Hände Nicht sehr wichtig. Wenige Punkte. Wenn du viele Tastaturen machst, können wir die schiefsten nachher wegschmeißen. (?) > Das bis hierher entwickelte gemischt-ganzzahlige lineare > Optimierungsmodell habe ich mal an die Mail angehängt, falls sich jemand > mit solchen Modellen auskennt, kann er ja mal einen Blick darauf > werfen. > > Ich bin jetzt beim Zusammenstellen der Parameter, und dann werde ich das > mal umsetzen und schauen, ob es noch mit Standardoptimierungssoftware > lösbar ist. Ansonsten ist auch denkbar, sequenziell vorzugehen, also > beispielsweise zuerst die wichtigsten zwölf Tasten zu fixieren und dann > die weiteren. Ja. Das hast du ja schon mal ges
Re: [Neo] Gemischt-ganzzahlig-linearer Optimierungsansatz
> Das bis hierher entwickelte gemischt-ganzzahlige lineare > Optimierungsmodell habe ich mal an die Mail angehängt, falls sich jemand > mit solchen Modellen auskennt, kann er ja mal einen Blick darauf > werfen. Danke. Ich kenn mich zwar nicht aus, habe aber trotzdem einen Blick darauf geworfen. Auf der rechten Seite von (7) müssen x'e statt z's stehen, für die z's passen die Indices nicht. Zudem kann in der Klammer etwas negatives stehen; ist das ein Problem? Sollte man nicht ein Produkt zweier x'e statt z+z-1 (bzw. x+x-1) haben, oder ist das dann nicht mehr gemischt-ganzzahlig linear? Interessant finde ich Gleichung (3). Kann man diese Bedingung verallgemeinern? Man stelle sich vor, eine Tastatur mit zwei e's, von denen man jeweils das bequemere tippt? Andreas