Wunsch: neue Funktion um Variablen zu setzen

[t31]

Hallo,

meist wird sehr oft ein Datum/Zahl abgefragt und dies dann Buchstaben zugeordnet.

Beispiel: Wie hoch ist die Schneekoppe (ABCD)? Nun muß man bisher alles einzeln Eintragen: A=1;B=6;C=0;D=2 was natürlich unterwegs nicht so gut ist.

Mir wäre hier eine Funktion lieber, die die Eingabe erleichtert.

ABCD=1602
s(ABCD)

s(), würde also den Variablenamen innerhalb der Klammer in einzelne Buchstaben separieren und ihn den jeweiligen Wert zuweisen. Noch praktische wäre s(ABCD)=1602 wenn das geht.

Erstere Variante hätte jedoch den Vorteil das auch folgendes umgesetzt werden könnte:

ABCD=1602
EFG=157
HIJKL=23408
s(ABCD,EFG,HIJKL)

 

[t31]

Ein anderer Ansatz wäre ein weitere Reiter im Löser mit einer Art vorgefertigten Tabellen A...Z wo man dann nur noch die Zahlen eintragen muß und eventuell ein paar weitere Zellen für zusätzliche Variablen (deren Namen fest vorgeben ist, z.B. A1..A6) für den Fall das ein Wort eingeben werden muß.

 

[MiK]

Ich bereite solche Caches meist daheim vor. Dann steht schon im Solver:

#Wie hoch ist die Schneekoppe (ABCD)?
A=
B=
C=
D=

Dann ist es unterwegs schnell eingetragen.

 

[pfeffer]

ich fänd's auch super, wenn es so eine fertige Tabelle gäbe, in die man bloß die Werte für A, B usw. eintragen muss.

Aber ich glaube, als alternative gibt es den Befehl skeleton oder so

Gruß,
Pfeffer.

 

[MiK]

skeleton baut nur das grobe Ablaufgerüst für Multis. Welche Variablen man an den Stages dann füllen muss, muss man noch selbst programmieren.

Das Thema mit dem Füllen mehrere Variablen in einer Zeile hatten wir schon mal. Das Problem ist, erst mal die gewollte Funktionsweise vollständig zu beschreiben. Wie soll die Syntax genau aussehen? Was passiert, wenn die Anzahl der Stellen nicht übereinstimmt? Soll man auch Variablen mit mehr als einem Buchstaben so füllen können? Wenn ja: Wie? Soll man auch mehrere Ziffern einer Variablen zuweisen können? Wenn ja: Wie?

Man muss dazu erst einmal Antworten finden. Und das Ergebnis muss dann auch noch leicht verständlich und einfach anwendbar sein.

Wenn das genau geklärt ist, ist das implementieren wohl nicht mehr so schwer.

 

[pfeffer]

ich fände so eine eigene Tabelle eh schöner, dann muss man nicht mehr die Buchstaben selbst tippen, sondern nur noch die Zahlen.
So ein mini-Excel wäre klasse ;-)
Darin würden links die Buchstaben vorgegeben sein und rechts schreibt man entweder eine Zahl oder eine Formel rein..., also ein Excel aus 2 Spalten, wobei die Spalten Namen von A-Z haben.
Dabei könnte man links die Buchstaben auch änderbar machen, sollten aber mit A-Z vorbelegt sein.

Gruß,
Pfeffer.

 

[MiK]

Ich finde die Vielfältigkeit des Solvers viel praktischer als eine starre Tabelle. Dafür sind die Multis viel zu unterschiedlich.

 

[t31]

Register mit Tabellenvorlage wäre sehr leicht umzusetzen, man könnte eine 5x5 Anordnung A bis Y, darunter Z und noch weitere Variablen A1... je nachdem was da noch an Platz bleibt, zuviel muß es nicht sein.

Steht nichts drin, dann ist die Variable undefiniert, eine 0 muß also geschrieben werden, schreibt man Text ist es automatisch ein String, das würde einem die "" ersparen


Das wäre sicher die einfachste Lösung, unten drunter hat man nach wie vor den Ausgabebereich, man kann also zwischen Code-Eingabe und Variableneingabe wechseln

Und weil ich das gerade lese, das soll natürlich nur eine Option und keine Pflicht sein, man kann also nach wie vor klassisch A=4 in der Codeansicht eingeben, wenn das einer so mag oder es nicht anders geht.

------------------
Das folgende ist umsetzbar aber sicher sehr kompliziert und schwer in ein Handbuch erklärbar

Vom Syntax her wäre s(ABCD)=1602 zwar ungewöhnlich aber nach längerem Überlegen doch die bessere Variante.

Das letzte Beispiel von oben könnte man auch so umsetzen:
s(ABCDEFGHIJKL)=160215723408

man könnte sogar
s()=160215723408
schreiben und so automatisch A...L zuweise lassen, ist natürlich nicht ganz ohne.

Bedingungen
- Zuweisung immer einstellig
- Variablenname ist immer nur ein Buchstabe
- Wenn weniger Buchstaben als Zahlen, dann Error
- Wenn weniger Zahlen als Buchstaben dann führende Nullen s(ABC)=25 wäre A=0;B=2;C=5 (man kann auch =025 schreiben, aber intern wäre es ja trotzdem =25, eine Fehlermeldung wäre auch denkbar, aber theoretisch könnten ja führende Nullen vorkommen und dann müsste man das in "" setzen, was auch wieder nicht so toll wäre)
- eventuell: Wenn keine Buchstaben, also s()=..., dann automatisch ab A bis Z je nachdem wieviel Stellen, führende Nullen gehen dann natürlich nicht, es besteht die Gefahr das man sich Variablem im Script ungewollt überschreibt, man muß da also wissen was man macht

-------------------------------------------

Auch interessant wäre die Sache mit den Positionen der Buchstaben einer Variable zuweisen, oft wird ein Wort gesucht und dann soll man den dritten Buchstaben nehmen und den sechsten.
Bisher löse ich das so:
s="Bierlager"
P=sval(mid(s,3,1))
T=sval(mid(s,6,1))
Das ist alles soweit kein Problem, aber halt nicht sehr übersichtlich, man schreibt sehr viel Code
In Analogie zu oben könnte man das auch umgestalten, wobei hier natürlich eine Variable auch einen zweistelligen Wert zugeordnet werden kann/muß.
sw(PT,3,6)="Bierlager" (P wäre danach =05 und T=01)

Auch hier könnte man einen Spezialfall implementieren für den Fall das alle Buchstaben benutzr werden sollen
sw(HIJKLMNOP)="Bierlager" (hier wäre H=02,...)
sw()="Bierlager" (hier wieder ab A, mit A=02, ...)

 

[Graf]

ich fände so eine eigene Tabelle eh schöner, dann muss man nicht mehr die Buchstaben selbst tippen, sondern nur noch die Zahlen.
So ein mini-Excel wäre klasse ;-)
Darin würden links die Buchstaben vorgegeben sein und rechts schreibt man entweder eine Zahl oder eine Formel rein..., also ein Excel aus 2 Spalten, wobei die Spalten Namen von A-Z haben.
Dabei könnte man links die Buchstaben auch änderbar machen, sollten aber mit A-Z vorbelegt sein.

Gruß,
Pfeffer.

Das sieht dann ungefähr so aus:

Ich finde die Vielfältigkeit des Solvers viel praktischer als eine starre Tabelle. Dafür sind die Multis viel zu unterschiedlich.

Ich würde es an eurer Stelle alternativ anbieten. Auch wenn die Multis oft unterschiedlich sind, gebt es auch sehr viele einfache, wo eine Tabelle ausreicht.

lg
Andreas

 

[Robin888]

Ich hatte vorgestern einen Geistesblitz!

Wenn ich zuvie^Hgenug Zeit beim Vorbereiten hatte, habe ich folgende Konstruktion benutzt um solche Aufgaben im Feld bequem zu lösen:

#Du findest hier die Jahreszahl ABCD

ABCD= #Jahreszahl

A=mid(ABCD,1,1)
B=mid(ABCD,2,1)
C=mid(ABCD,3,1)
D=mid(ABCD,4,1)

Mein Vorschlag wäre jetzt den skeleton-Begriff zu erweitern bzw. einen ähnlichen Befehl zu programmieren, der obiges konstruiert.

Also

sk(ABCD)

liefert

ABCD=

A=mid(ABCD,1,1)
B=mid(ABCD,2,1)
C=mid(ABCD,3,1)
D=mid(ABCD,4,1)

Das entspricht in natürlicher Weise meiner Vorstellung, daß einzelnen Buchstaben nur *Ziffern* zugeordnet werden und ist weitestgehend fehlerresistent.

Und falls irgendjemand mal doch was Spezielles anderes braucht, kann der den generierten Code selbst anpassen.

Was haltet ihr von der Idee?

Robin(888)

 

[ggcode]

Hi Robin,
also ich find das was MIK geschrieben hat auch am einfachsten

#Wie hoch ist die Schneekoppe (ABCD)?
A=
B=
C=
D=

ist doch am wenigsten Tipparbeit. Wenn ich das vorbereite, ist das so schnell eingetragen wie "irgeneinbefehl(ABCD)".

Gruß ggcode

 

[Robin888]

Ja, aber im Feld muß man zwischen den Ziffern die Zeile wechseln.

Aber im Grunde gebe ich euch Recht. Mach' ich selbst meistens so. (Ggfls. auch in einer Zeile.)

(Aber *wenn* Befehl, finde ich meinen Vorschlag am praktikabelsten.)

Robin(888)

 

[pfeffer]

ich würde das
A=
B=
usw. halt einfach in eine Tabelle machen, ähnlich wie schon $User ein Bildschirmfoto gemacht hat. Einfach nur, um bequem Variablen definieren zu können, denn: ich bereite in der Regel nix zu Hause vor --> alles soll schnell im Feld tippbar sein.

Gruß,
Pfeffer.

 

[MKW]

Eigentlich bin ich immer für neue Features, die das Cacherleben leichter machen, zu haben. Anderseits stößt der CW auf meinem kleinen Medion immer häufiger an Speichergrenzen und die Bildanzeige streikt. Und jede weitere Maske braucht Speicherplatz.

Ich finde, das die Eingabe von "A=23" o.ä. unterwegs wirklich kein Problem ist. Viel schlimmer ist das Formatieren der mit cut/paste eingesetzten Formeln zur Koordinatenberechnung. Wo müssen Anführungszeichen hin? Sind alle Variablen durch Leerzeichen getrennt? Besonders störend: ist das Komma von Anführungszeichen eingeschlossen? Muß ein "x" als Multiplikationszeichen durch "*" ersetzt werden? Besondere Freude lösen bei mir immer wieder die fehlen Nullen nach dem Komma aus, wenn das Ergebnis nicht dreistellig ist.

Im Vergleich dazu ist ein einfaches Zuweisungsstatement schnell geschrieben und deswegen sollte dafür kein Speicherplatz verbraucht werden.
Wer sich die Arbeit vereinfachen will, der kann eine Wordpaddatei "A= B=" usw. anlegen und von dort mit cut/paste die benötigten Zuweisungen einmal an den Anfang des "Programms" in das Solverfenster kopieren.

Ein Split-Statement, so wie es ursprünglich vorgeschlagen wurde, halte ich für sinnvoll.
Könnte der Parser folgendes verarbeiten:

(A b R1 HA) = split(1962)

?
Das Ergebnis soll dann A=1 b=9 R1=6 HA=2 sein.
Die vorgeschlagene "Automatik", bei der als Default die Zuweisung zu A,B,… erfolgt, halte ich für überflüssige Programmierarbeit. Dieses Verhalten käme höchstens einmal pro Cache vor. Das lohnt nicht.

 

[Robin888]

Eigentlich bin ich immer für neue Features, die das Cacherleben leichter machen, zu haben. Anderseits stößt der CW auf meinem kleinen Medion immer häufiger an Speichergrenzen und die Bildanzeige streikt. Und jede weitere Maske braucht Speicherplatz.

ACK!

Viel schlimmer ist das Formatieren der mit cut/paste eingesetzten Formeln zur Koordinatenberechnung.

Das geht mit etwas Übung ganz flott am PC. Du hast zwar recht, daß hält am meisten auf, aber solange keine einheitliche Schreibweise verpflichtend wird, lässt sich das nur sehr schlecht irgendetwas parsen.
Meine "Tipps":

Wo müssen Anführungszeichen hin?

Vor dem N und dann immer "abwechselnd". Aufpassen, daß vor dem Ost-E ein Leerzeichen steht. (Und am Ende meistens nicht.)

Sind alle Variablen durch Leerzeichen getrennt?

Zur Not immer Klammern drum. Dann ist auch ein Leerzeichen unnötig. ;-)

Besonders störend: ist das Komma von Anführungszeichen eingeschlossen?

Ach, so störend empfinde ich das nicht. Macht es nur etwas unübersichtlich, beim Kontrollieren.

Muß ein "x" als Multiplikationszeichen durch "*" ersetzt werden?

Ja.

Besondere Freude lösen bei mir immer wieder die fehlen Nullen nach dem Komma aus, wenn das Ergebnis nicht dreistellig ist.

Dazu habe ich vielleicht sogar einen hilfreichen Tipp!
Wenn die Dezimalstellen durch eine Berechnung definiert sind, einfach ein ":000:" hintersetzen. Das erzwingt eine dreistellige Ausgabe. (Analog :00: oder :00.000

Wer sich die Arbeit vereinfachen will, der kann eine Wordpaddatei

*autsch* Text-Datei!?

"A= B=" usw. anlegen und von dort mit cut/paste die benötigten Zuweisungen einmal an den Anfang des "Programms" in das Solverfenster kopieren.

Dazu muß man aber erstmal die gesamte Beschreibung per Auge "parsen, welche Variablen man braucht. Leere Zuweisungen spucken nämlich Fehler aus. .-(

Ein Split-Statement, so wie es ursprünglich vorgeschlagen wurde, halte ich für sinnvoll.
Könnte der Parser folgendes verarbeiten:

(A b R1 HA) = split(1962)

?
Das Ergebnis soll dann A=1 b=9 R1=6 HA=2 sein.

Das halte ich wieder für überflüssigen Programmieraufwand.
Zumal mir es noch nie untergekommen ist, daß man in einer solchen Situation wirklich mehrstellige Variablen hat.

Die vorgeschlagene "Automatik", bei der als Default die Zuweisung zu A,B,… erfolgt, halte ich für überflüssige Programmierarbeit. Dieses Verhalten käme höchstens einmal pro Cache vor. Das lohnt nicht.

Ich glaube da hat auch niemand von gesprochen, oder? Mein Parser zum Beispiel käme auch damit zurecht:

sk(MKV)

liefert

ABCD=

M=mid(ABCD,1,1)
K=mid(ABCD,2,1)
V=mid(ABCD,3,1)

Robin(888)

 

[MiK]

Dazu muß man aber erstmal die gesamte Beschreibung per Auge "parsen, welche Variablen man braucht. Leere Zuweisungen spucken nämlich Fehler aus. .-(

Sicher? Bei mir gibt es bei einer leeren Zuweisung erstmal keinen Fehler. Nur wenn man die Variable dann verwenden will.

sk(MKV)

liefert

ABCD=

M=mid(ABCD,1,1)
K=mid(ABCD,2,1)
V=mid(ABCD,3,1)

Äh... wenn Du Dein Beispiel schon anpasst, solltest Du es richtig machen ;-)

Wenn wir jetzt mal von "im Feld" ausgehen und davon, dass die aufzuteilende Zahl nicht mehr als 4 Stellen hat, braucht keine der Lösungen "im Solver" wesentlich weniger Klicks, als die vier Zeilen von Hand zu schreiben.

Zur separaten Eingabemaske für Variablen: Nach meinem Geschmack ist das zu unflexibel und unübersichtlich. Man hat dann ja den Rest des Solvercodes inkl. der Frage im Kommentar nicht mehr im Blick. Und jedes Fenster-Umschalten kostet auf dem PDA Zeit. Und bei dem Beispiel mit der vierstelligen Zahl bringt es auch keinen großen Vorteil. Je nach Eingabeposition kostet das im Solver 15-16 Klicks und in einer Eingabemaske 9-10 Klicks (inkl. Hin- und Herwechseln zum Solver. Im Vergleich mit der Formeleingabe ist das vernachlässigbar.

 

[MKW]

Da hat der liebe Robin mich ziemlich mißverstanden. Ich weiß natürlich, wie man eine Koordinate aufbereitet. Die Fragen sind rhetorischer Natur und sollten nur den "Aufwand" zeigen, den es dafür braucht.

Der Tip zur Formatierung mit :000: ist hilfreich, bedeutet aber noch mehr Schreiberei.

Was schön wäre, wäre wenn der Parser ein Komma bzw. einen Punkt wie eine Zahl ohne Anführungszeichen verstehen würde. Das würde vier Anführungszeichen pro Koordinate sparen.

Die Default-Idee war übrigens von t31.(s.o.)

@Robin: Wie soll deine sk-Erweiterung praktisch funktionieren? Die einzige Lösung wäre ein Aufruf aus der Promptzeile, der dazu führt, daß an der Stelle, an der der Cursor im Code steht, die Expansion eingefügt wird. "ABCD" wäre dann also eine geschützte Variable?

 

[t31]

Möchte nochmal sagen, das es zunächst mal alles nur Idee/Vorschläge sind. Ziel bzw. mein Wunsch ist einfach auch ein Mystery spontan anzugehen ohne Zettel und Stift, man ist bereits unterwegs, drausen ist es eventuell noch kalt und nass - man freut sich also über jede Funktionalität die einem das Cacherleben einfacher macht.

Zuhause planen und den Solver vorbereiten ist kein Problem. Ist man aber Unterwegs und hat noch nichts vorbereitetes muß es schnell gehen, Zeilenumbrüche erfordert scrollen (darum schreibe ich viel auf eine Zeile, das Listing wird sonst schnell lang und ist nicht mehr auf einen Blick zu sehen), was auf den PPC auch immer recht ruckelig ist, Einfügen nach dem Kopieren geht auch nicht an der Cursorposition (man braucht ein dummy-Zeichen, das man markiert, sonst erscheint das Kontextmenü nicht), es sind eben die Kleinigkeiten, wie ;""() die auch immer das Umschalten (Shift) erfordern usw.

Beim letzten Cache habe ich den PPC auch nur zum lesen der Beschreibung und die sval("Wort")-Funktion benutzt (erspart Abzählen und Fehler) und den Rest auf dem Papier, geht letztlich eben so schneller. Erst dadurch kam überhaupt der Wunsch auf.

 

[Robin888]

Dazu muß man aber erstmal die gesamte Beschreibung per Auge "parsen, welche Variablen man braucht. Leere Zuweisungen spucken nämlich Fehler aus. .-(

Sicher? Bei mir gibt es bei einer leeren Zuweisung erstmal keinen Fehler. Nur wenn man die Variable dann verwenden will.

Nein. Nicht sicher.
Ich habe es grad nochmal nachverfolgt, und das Problem war anderer Natur.
Aber dennoch wäre eine komplette Liste möglicher(!) Variablen doch etwas unhandlich.

Äh... wenn Du Dein Beispiel schon anpasst, solltest Du es richtig machen ;-)

Sorry, war unter Zeitdruck (wie jetzt eigentlich auch...) Sollte natürlich heißen:

sk(MiK)

liefert

MiK=

M=mid(MiK,1,1)
i=mid(MiK,2,1)
K=mid(MiK,3,1)

Wenn wir jetzt mal von "im Feld" ausgehen und davon, dass die aufzuteilende Zahl nicht mehr als 4 Stellen hat, braucht keine der Lösungen "im Solver" wesentlich weniger Klicks, als die vier Zeilen von Hand zu schreiben.

Naja, bei häuslicher Vorbereitung braucht man bei den meisten Vorschlägen fünf bis sechs Taps (Cursor setzen, ggfls. Tastatur anzeigen, vier Ziffern).
Ohne Vorbereitung braucht mein Vorschlag *rechne* 15-17 Taps:
Cursor setzen, ggfls. Tastatur anzeigen, sk, [Capslock], (, ABCD, ), "Rechne", ggfls. Cursor setzen (falls das nicht automatisch geht), Ziffer, Ziffer, Ziffer, Ziffer

Per Hand sind es:
Cursor setzen, ggfls. Tastatur anzeigen,
[Shift], A, [Shift], =, Ziffer, [Return]
[Shift], B, [Shift], =, Ziffer, [Return]
[Shift], C, [Shift], =, Ziffer, [Return]
[Shift], D, [Shift], =, Ziffer

= 25-26 Taps

OK, hält (bei vier Stellen) sich in Grenzen. Wenn ich Zeit habe kann ich das ja nochmal in Abhängigkeit von n berechnen. B-)

Allerdings will ich auf die Eleganz hinweisen, die es meiner Meinung nach besitzt, ein gefundenes Datum auch ein seiner "Reinform" aufzuschreiben anstatt von vornherein die Zahl zu zerlegen.

Zur separaten Eingabemaske für Variablen

ACK.

Robin(888)

 

[Robin888]

Da hat der liebe Robin mich ziemlich mißverstanden. Ich weiß natürlich, wie man eine Koordinate aufbereitet. Die Fragen sind rhetorischer Natur und sollten nur den "Aufwand" zeigen, den es dafür braucht.

Der Gedanke ist mir beim Beantworten durchaus gekommen.

Der Tip zur Formatierung mit :000: ist hilfreich, bedeutet aber noch mehr Schreiberei.

Naja, das ist dann halt so. Wäre schon kontraintuitiv, wenn Zahlen auf einmal automatisch dreistellig interpretiert würden. Das wäre genau das Quentchen "intelligente Technik", die mich stören würde.
Aber die Formatierungszeichen braucht man ja auch nicht bei jeder Berechnung. Oft werden ja die Ziffern einzeln bestimmt.
(Dafür werden bei anderen Multis die Minutenwerte fünfstellig berechnet. Wenn man da nicht im Vorraus weiß, in welcher Dimension das Ergebnis vorliegen wird (10.123 oder 10123), dann kriegt man das nur schwer in den Griff...)

Was schön wäre, wäre wenn der Parser ein Komma bzw. einen Punkt wie eine Zahl ohne Anführungszeichen verstehen würde. Das würde vier Anführungszeichen pro Koordinate sparen.

Jepp. Wieso macht er das eigentlich nicht?
Bei einem Komma meckert er

Erwartet:; Gefunden:,

und bricht ab und bei einem Punkt fäng er noch nicht mal an, sondern meldet

Nicht erlaubtes Zeichen

Werden die Zeichen irgendwofür benötigt?

Wie soll deine sk-Erweiterung praktisch funktionieren? Die einzige Lösung wäre ein Aufruf aus der Promptzeile, der dazu führt, daß an der Stelle, an der der Cursor im Code steht, die Expansion eingefügt wird.

Hm. Ich dachte der skeleton-Befehl würde jetzt auch schon seine Expansion an seine Stelle setzen und dann erstmal abbrechen. Dem ist aber nicht so, die Expansion kommt ans Ende und der Rest der Datei wird auch berechnet. %-o

Also gedacht war:
Wenn der Befehl auftaucht, schreibt er seine Expansion an *seine* Stelle und stoppt das Programm. (Und setzt am besten den Cursor hinter das Gleichheitszeichen.)

"ABCD" wäre dann also eine geschützte Variable?

Was für eine Variable? 0

Robin(888)