• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Wie nutzt ihr den Solver für Multis?

MiK

Geoguru
Hallo CW-Nutzer,

im CW gibt es ja mit dem Solver und darin dem Befehl skeleton() der ein Gerüst für Multis erzeugt eine sehr gute Unterstützung für das Vorbereiten und abarbeiten von Multis. Ich weiß nicht wie viele das überhaupt nutzen, aber ich habe die Erfahrung gemacht, dass ein im Solver gut vorbereiteter Multi viel mehr Spaß macht. Vor allem muss man nicht doch wieder Zettel und Papier mit sich rumtragen. Damit viele in den Genuss dieses Features kommen können, ist es wichtig, dass die Vorbereitung schnell und einfach geht. Und mit wenig Aufwand auch mal im Feld erledigt werden kann.

Deswegen meine Frage: Wie geht ihr bei der Vorbereitung eines Multis im Solver vor? Welche Features würden Euch dabei helfen bzw. fehlen Euch noch, damit ihr es überhaupt mal versucht?

Hier einmal meine Vorgehensweise für Multis im Solver:

Die meisten Caches, die ich im Solver vorbereitet habe waren von der Art: Gehe zu einem Punkt, schreibe ein paar Zahlen ab, mache ein paar Rechenoperationen damit und trage mehrere von den Variablen in die Koordinaten für die nächste Stage ein.

Ich habe das dann immer folgendermaßen umgesetzt: Oben kopiere ich die Beschreibung hin. Kürze irrelevante Teile heraus, so dass dort immer nur noch steht, was an der Stage gesucht werden muss und darunter dann a=, b= usw. für diese Stage. Unter diese Beschreibungen und Zuweisungen kommt das das Gerüst aus sk(), wo ich die jeweiligen Berechnungen und Einsetzungen eintrage.

Im Feld brauche ich die Beschreibung dann fast nicht mehr. Ich scrolle im Solver zu der Stelle der Stage, löse die Aufgabe, trage die Zahlen ein, Klicke "Rechne" und auf gehts zu nächsten Stage.

Das sieht dann am Beispiel GCMP52 so aus:
Code:
#Station 1: N49 51.901 / E8 36.201
#Ein Bauwerk mitten auf der Straße, in Deutschland natürlich streng nach DIN. Mit der passenden Nummer kann es los gehen. -> DIN1ab8c
a=
b=
c=
#Station 2: N49 51.a21 / E8 36.cb0
#Diesen Verein gibt es schon sehr lange. Das Gründungsjahr führt Euch zur nächsten Station. -> 19de
d=
e=

...

#Station 8: N49 51.k2n / E8 36.moo
#Das "Schwimmbad" kurz vor dem Final hat geschlossen. Welche Wassertiefe kann maximal gemessen werden? -> pqq cm
p=
q=
#Final: N49 51.iao / E8 36.qpn

IF $01MP52="" THEN
   $01MP52="N49 51."a"21 E8 36."c b"0"
   "Station 2 = " $01MP52
   goto($01MP52); STOP
ENDIF
IF $02MP52="" THEN
   $02MP52="N49 51.7"e e" E8 36.7"d e
   "Station 3 = " $02MP52
   goto($02MP52); STOP
ENDIF

...

IF $08MP52="" THEN
   $08MP52="N49 51."i a o" E8 36."q p n
   "Final = " $08MP52
   goto($08MP52); STOP
ENDIF
 

greiol

Geoguru
das nervigste bei der vorbereitung sind für mich:
- superlustige klammerungen in der cachebeschreibung (bevorzug in der variante ungeradeklammerzahl oder [])
- verwendung von gedanken oder bindestrichen in rechenformeln statt einem minus

nach einem kurzen blick in die beschreibung entscheide ich mich ob ich den solver überhaupt benutze oder ob ich nicht ein paar zahlen schnell auf einen papierschnipsel kritzel und das ganze doch von hand mache.

ich überlege die ganze zeit ob es sinn machen könnte ein repository für fertige multiformeln einzurichten bei dem jeder seine noch nicht mit konkreten werten gefüllten formeln zusammen mit einem kleinen gpx welches die notwendigen/fehlenden AWs anlegt einzurichten. so müsste das rad nicht immer neu erfunden werden.
 
OP
MiK

MiK

Geoguru
greiol schrieb:
das nervigste bei der vorbereitung sind für mich:
- superlustige klammerungen in der cachebeschreibung (bevorzug in der variante ungeradeklammerzahl oder [])
- verwendung von gedanken oder bindestrichen in rechenformeln statt einem minus
Da müsste man mal schauen, ob man den Solver toleranter machen könnte.

greiol schrieb:
ich überlege die ganze zeit ob es sinn machen könnte ein repository für fertige multiformeln einzurichten bei dem jeder seine noch nicht mit konkreten werten gefüllten formeln zusammen mit einem kleinen gpx welches die notwendigen/fehlenden AWs anlegt einzurichten. so müsste das rad nicht immer neu erfunden werden.
Zusätzliche Waypoints sind eigentlich nicht nötig. Im Prinzip würde Plaintext ausreichen, den man dann einfach in den Solver kopiert. Ich bin trotzdem eher dafür den solver so komfortabel wie möglich zu machen, So dass ihn jeder schnell selbst benutzen kann. So ist man einfach flexibler.
 

Kalli

Geowizard
Hier mein eher kontraproduktiver Beitrag: Ich habe einen A5-Block dabei, auf dem ich die Ergebnisse notiere und Berechnungen ausführe. Als Programmierer traue ich Code (insbesonders dem von mir geschriebenen) erst mal nicht über den Weg, bis ich es getestet habe. Wenn man sich dann wegen eines Bugs verläuft, ist es blöd, doppelt blöd wenn meine Freundin dabei ist, dann kann ich mir noch irgendwelche Kommentare anhören. Außerdem fehlt mir am PDA etwas die Übersicht, wenn die Tastatur eingeblendet ist.

Ich habe den Solver aber schon zur Nachbearbeitung von Caches genutzt, die ich nicht gefunden habe, weil eine Station gefehlt hat. Bei Mysteries, wo man zu Hause Sachen berechnet, ist es bestimmt auch sinnvoll.
 
OP
MiK

MiK

Geoguru
Kalli schrieb:
Hier mein eher kontraproduktiver Beitrag: Ich habe einen A5-Block dabei, auf dem ich die Ergebnisse notiere und Berechnungen ausführe. Als Programmierer traue ich Code (insbesonders dem von mir geschriebenen) erst mal nicht über den Weg, bis ich es getestet habe. Wenn man sich dann wegen eines Bugs verläuft, ist es blöd, doppelt blöd wenn meine Freundin dabei ist, dann kann ich mir noch irgendwelche Kommentare anhören. Außerdem fehlt mir am PDA etwas die Übersicht, wenn die Tastatur eingeblendet ist.

Ja, ich hab da auch berufsbedingt ähnliche Zweifel. Seltsamerweise sind mir aber im Solver noch nie Fehler passiert...

Zur Übersicht am PDA: Schön wäre hier, wenn der Ausgabebereich evtl. ausgeblendet werden könnte während der Eingabe. Weiß nicht, ob wir das mitbekommen, wenn die Tastatur eingeblendet wird.
 

salzkammergut

Geomaster
MiK schrieb:
greiol schrieb:
- superlustige klammerungen in der cachebeschreibung (bevorzug in der variante ungeradeklammerzahl oder [])
- verwendung von gedanken oder bindestrichen in rechenformeln statt einem minus
Da müsste man mal schauen, ob man den Solver toleranter machen könnte.
@Mik: Das geht sicher. Über den Gedankenstrich bin ich auch schon gestolpert. Die eckige Klammer kann man genau wie eine runde Klammer behandeln. Bei ungeraden Klammern ist es aber besser wenn eine Fehlermeldung kommt anstatt ein eventuell falsches Ergebnis zu liefern.

Mik schrieb:
Schön wäre hier, wenn der Ausgabebereich evtl. ausgeblendet werden könnte während der Eingabe.
Daß Du den Eingabebereich durch Doppelklick auf die Trennleiste zwischen den Fenstern maximieren kannst reicht nicht?

Kalli schrieb:
Ich habe einen A5-Block dabei
@Kalli: Shame on you. Als CW Mitautor ... :wink:
 
OP
MiK

MiK

Geoguru
salzkammergut schrieb:
@Mik: Das geht sicher. Über den Gedankenstrich bin ich auch schon gestolpert. Die eckige Klammer kann man genau wie eine runde Klammer behandeln. Bei ungeraden Klammern ist es aber besser wenn eine Fehlermeldung kommt anstatt ein eventuell falsches Ergebnis zu liefern.i
Sehe ich genauso. Einzelne Zeichen sollten tollerant behandelt werden. Falsche Klammerzahlen natürlich nicht.
salzkammergut schrieb:
Daß Du den Eingabebereich durch Doppelklick auf die Trennleiste zwischen den Fenstern maximieren kannst reicht nicht?

Habe es gerade mal versucht. Ist ziemlich frickelig. Beim ersten Klick wird der Ausgabebereich maximiert. Beim nächsten dann der Eingabebereich. Direkt gehts dann gar nicht weiter. Erst wenn man die Tastatur geschlossen hat. Wenn es automatisch gehen würde, wäre es schon praktischer.

Hat jemand eine Idee, wie man den Rechne!-Button noch sparen könnte? Das würde auch noch ein bisschen Platz sparen.

Außerdem wäre es schön, wenn die Tastatur automatisch verschwinden würde, wenn man dann zum Goto-Panel schaltet.
 

greiol

Geoguru
heute mal wieder mit dem solver unterwegs gewesen. was für eine blamage :oops: aber wir hatten ein stück papier dabei und das hat uns rausgerissen.

ich hatte einen syntaxfehler drin, den ich auf die schnelle erst mal nicht gefunden habe (zeilen und spalten zählen auf dem pda ist mühsam). nun überlege ich wie ich meine formeln vor dem cachen sinnvoll testen kann (zumindest auf syntax).

trage ich dummwerte ein und die syntax stimmt, werden mir die wegpunkte mit koordinaten gefüllt und der teil mit den IF-abfragen funktioniert nicht mehr. ich kann auch die wegpunkte hinterher nicht mehr auf "undef" setzen. also bleibt mir nur die ausgerechneten wegpunkte aus der db zu löschen und wieder neu anzulegen.

oder wie macht ihr das?
 
OP
MiK

MiK

Geoguru
greiol schrieb:
ich hatte einen syntaxfehler drin, den ich auf die schnelle erst mal nicht gefunden habe (zeilen und spalten zählen auf dem pda ist mühsam).
Eigentlich springt der Cursor zur Fehlerstelle. Bin mir aber nicht sicher, ob das immer zuverlässig funktioniert.

greiol schrieb:
trage ich dummwerte ein und die syntax stimmt, werden mir die wegpunkte mit koordinaten gefüllt und der teil mit den IF-abfragen funktioniert nicht mehr. ich kann auch die wegpunkte hinterher nicht mehr auf "undef" setzen. also bleibt mir nur die ausgerechneten wegpunkte aus der db zu löschen und wieder neu anzulegen.
Werden die Werte auch in den Addis gespeichert, wenn CW ohne Speichern beendest? Ich bin aber auch dafür, dass man Koordinaten wieder auf "nicht gesetzt" setzen kann. Entweder durch einen Button im Koordinaten-Dialog, oder dadurch, dass der Koordinaten-Dialog bei "fehlerhaften" Eingaben auf "nicht gesetzt" setzt.

Eine schöne Lösung zum Solver-Testen ist das aber auch noch nicht. Vielleicht sollten wir einen "Check Syntax"-Button in den Solver bauen. Weiß aber nicht, wie kompliziert der Code dahinter wird.
 

greiol

Geoguru
MiK schrieb:
Eigentlich springt der Cursor zur Fehlerstelle. Bin mir aber nicht sicher, ob das immer zuverlässig funktioniert.
das hat bei den stellen an denen ich konstruktionen wie AB statt (A)(B) stehen hatte auch sehr gut geklappt (würde da eigentlich auch A B gehen?).
mein Problem waren in dem fall fehlende ". da würde es zumindest helfen wenn die richtige zeile angesprungen würde. ich hatte den eindruck er bleibt einfach an der aktuellen cursorposition stehen und beim abzählen bin ich irgendwie regelmäßig in der falschen zeile gelandet.
 

salzkammergut

Geomaster
In der neuesten BE habe ich die Anzeige der Fehlerstelle verbessert: Es wird jetzt vom Beginn der Fehlerzeile bis zum Fehler selektiert (=invertiert dargestellt). Ein Klick in das Fenster bringt die Selektion wieder zum Verschwinden. Bei (häufig vorkommenden) fehlenden Hochkommas, wird bis zum Hochkomma, dem der Abschluß fehlt selektiert, Du weißt also sofort wo das Problem ist.

greiol schrieb:
würde da eigentlich auch A B gehen?
Ja, alles im Sinne der Minimierung von unnötigen Eingaben

Beispiel:
Code:
A=3;B=4
A B          => 34
A B:000:     => 3004
(A B):000:   => 034
Anmerkung: Die Zeichenfolge :000: ist eine Formatierungsanweisung, die besagt daß das Ergebnis auf drei Stellen mit führenden Nullen zu formatieren ist.
 

Kappler

Geowizard
Wegen dem Problem mit dem WPs auf undef. setzen:
Ich trage am Ende des Skeletts immer novh folgendes ein:

$GC... = ""

und zwar für alle WPs, die im Skelett gefüllt werden.

Dies setzt diese wieder auf undef.

Hiermit kann ich Dummy-Werte eintragen um die Syntax zu testen. Bei jedem "Rechnen"-Schritt wird ein weiterer Wegpunkt berechnet und eingetragen, nach dem Letzten werden alle WPs wieder auf undef. gesetzt.
Dies hat bei mir bisher noch jeden Syntaxfehler gefunden. (problematisch wird es nur, wenn bei den Dummywerten fehlerhafte Koordinaten rauskommen, dann bricht die Berechnung zwischendurch ab)

Eventuell könnte man im skeleton()-Befehl auch das ""-setzen der WPs mit einbauen? Von Hand unterwegs ist es doch etwas mühsam.
 
OP
MiK

MiK

Geoguru
Kappler schrieb:
Eventuell könnte man im skeleton()-Befehl auch das ""-setzen der WPs mit einbauen? Von Hand unterwegs ist es doch etwas mühsam.
Der Gedanke kam mir auch erst. Die Frage ist, ob man die Wegpunktkoordinaten nicht evtl. doch zur Dokumentation speichern möchte.

Aber man könnte es natürlich anhängen und nach der Vorbereitung zum "scharfschalten" entfernen.
 
OP
MiK

MiK

Geoguru
Wie kompliziert wäre es eigentlich nur die Syntax zu checken ohne den Code auszuführen? Das wäre doch die eleganteste Lösung, oder?

Was mir gerade noch beim Studium der Doku aufgefallen ist:
Die trigonometrischen Funktionen arbeiten in Radiant. Vielleicht sollten wir da auch noch Umrechnungsfunktionen in Grad anbieten oder zumindest eine Konstante Pi.
 

salzkammergut

Geomaster
Mik schrieb:
Die trigonometrischen Funktionen arbeiten in Radiant. Vielleicht sollten wir da auch noch Umrechnungsfunktionen in Grad anbieten oder zumindest eine Konstante Pi.
Ich habe das vom alten Solver so übernommen, aber eigentlich wäre es logisch generell in Grad zu arbeiten. Was meint ihr?

Mik schrieb:
Wie kompliziert wäre es eigentlich nur die Syntax zu checken ohne den Code auszuführen?
Muß ich mal anschauen. Der Code besteht aus zwei Teilen: Dem Tokenizer und dem Parser. Der Tokenizer zerlegt die Befehle in Tokens und findet einige einfache Fehler, z.B. nicht abgeschlossene Zeichenketten. Er kann aber nicht erkennen daß "A +- B" ein Fehler ist, das macht erst der Parser.

Zum Thema Skeleton:

Es gibt hier offsensichtlich doch persönliche Präferenzen. Eine nicht zu schwierig zu implementierende Möglichkeit wäre, das Skelett in einer Vorlage (Template) zu speichern, die als Textdatei im CW Verzeichnis liegt. Profis können dann diese Vorlagedatei nach eigenen Wünschen ändern und sich so ihr persönliches "Skelett" erstellen. Eure Meinung?
 
OP
MiK

MiK

Geoguru
salzkammergut schrieb:
Mik schrieb:
Die trigonometrischen Funktionen arbeiten in Radiant. Vielleicht sollten wir da auch noch Umrechnungsfunktionen in Grad anbieten oder zumindest eine Konstante Pi.
Ich habe das vom alten Solver so übernommen, aber eigentlich wäre es logisch generell in Grad zu arbeiten. Was meint ihr?
Da hätte ich auch nichts dagegen. Trotzdem könnten Umrechnungsfunktionen und Pi-Konstante hilfreich sein

salzkammergut schrieb:
Mik schrieb:
Wie kompliziert wäre es eigentlich nur die Syntax zu checken ohne den Code auszuführen?
Muß ich mal anschauen. Der Code besteht aus zwei Teilen: Dem Tokenizer und dem Parser. Der Tokenizer zerlegt die Befehle in Tokens und findet einige einfache Fehler, z.B. nicht abgeschlossene Zeichenketten. Er kann aber nicht erkennen daß "A +- B" ein Fehler ist, das macht erst der Parser.
Könnte man dann dem Parser nicht jeder Zeile mal vorwerfen und schauen, ob er damit zurecht kommt? Natürlich ohne dass globale Variablen dadurch geändert werden. Dann hätte man schon fast alle Systaxfehler (Bis auf Kontrollstrukturen) abgedeckt, oder?

salzkammergut schrieb:
Zum Thema Skeleton:

Es gibt hier offsensichtlich doch persönliche Präferenzen. Eine nicht zu schwierig zu implementierende Möglichkeit wäre, das Skelett in einer Vorlage (Template) zu speichern, die als Textdatei im CW Verzeichnis liegt. Profis können dann diese Vorlagedatei nach eigenen Wünschen ändern und sich so ihr persönliches "Skelett" erstellen. Eure Meinung?

Eigentlich habe ich noch keine alternativen Gerüstvorschläge hier gehört. Wenn man mal von dem Syntax-Check-Workaround absieht. Klar wäre es für Poweruser ein schönes Feature, aber eigentlich sollte es einigermaßen deterministisch sein, was die Befehle einer Sprache tun. Sonst gibt es nur Probleme, wenn hier Fragen beantwortet und Tipps gegeben werden sollen.

Also skeleton selbst würde ich nicht anfassen. Aber vielleicht könnte man einen extra template()-Befehl einführen, dem man den Namen von eigenen Templates im Programmverzeichnis übergeben kann. Man könnte ja eine Endung wie .stl für Solvertemplate festlegen und man kann dann mit template("supermulti") das eigene template supermulti.stl aufrufen.

Dann bleibt das Standardgerüst erhalten und man kann dort beliebige Codeschnipsel hinterlegen. Vielleicht sollte man dazu auch noch ein einfaches Loopen über alle Addis einführen.
 

greiol

Geoguru
salzkammergut schrieb:
wäre eine möglichkeit. ich könnte etwas ohne goto brauchen, denn ich benuitze den cw eh nicht zum laufen sondern nur zum rechnen. andereseits scheint es derzeit nicht zu stören, wenn ein goto aufgerufen wird aber kein signal anliegt. also ...
 

thomas_st

Geowizard
Ich komme mal auf die Ausgangsfrage zurück.
MiK schrieb:
Wie geht ihr bei der Vorbereitung eines Multis im Solver vor?
Da ich den PDA "nur" als Datengrab nutze, ist für mich die goto-Funktion relativ nutzlos. Bisher habe ich eigentlich nur die Koordinatenberechnungen aus der Cachebeschreibung übernommen (C&P), mit Hochkommas versehen, die Variabelenzuweisungen davor gesetzt und das Ganze einfach nur ausgegeben. Die KO kamen dann in das Hand GPS und los ging's. Das ganze mache ich - wenn ich lustig bin - zu Hause (dann kommt noch ein stop in die Berechnung) oder häufiger erst unterwegs.

MiK schrieb:
Welche Features würden Euch dabei helfen bzw. fehlen Euch noch, damit ihr es überhaupt mal versucht?
Da bin ich bisher zufrieden gestellt, nur einen kleine Wunsch hätte ich: oft sind größere Zahlen (zu 98% sind es Jahrszahlen) in einzelne Stellen zu zerlegen, die dann wieder einzeln weiter genutzt werden - z.B. "Diese Gebäude wurde im Jahre ABCD gebaut. Gehe nun zu den KOs N 08°15.D1A' und E 047°11.BC8'." Hier würde eine Funktion helfen, die dieses "Zerlegen" in einzelne Variable gestatten würde (und damit meine ich jetzt nicht über ein Zerlegen der Zeichenkette mit mid() und Variabelenzuweisung der einzelnen Stellen (geht das eigentlich, dass eine Zeichenkette später als numerischer Wert genutzt werden kann - ich meine eine "1" ist dann eine 1?). Das ist mir unterwegs dann zu viel Tipparbeit.

salzkammergut schrieb:
Ich habe das vom alten Solver so übernommen, aber eigentlich wäre es logisch generell in Grad zu arbeiten. Was meint ihr?
Halte ich im Fall GC für sinnvoll - in den wenigsten Fällen wird man wohl rad benötigen. Wenn dann noch die Variable Pi verfügbar wäre, wären diese paar Fälle auch erschlagen.

Gruß,
Thomas(_st)
 

lahmer

Geocacher
Mir sind bei der Nutzung des Solvers mehrere "negative" Dinge aufgefallen (vielleicht passiert das ja mit ein wenig Übung nicht mehr):

- Kommazahlen sind in den Beschreibungen meist auch mit Komma angegeben, der Parser überschlägt sich dabei aber und will einen Punkt haben (leider war der Cursor zu der Zeit nicht genau an der Fehlerstelle, so dass ich mir da erstmal nen Wolf gesucht habe).

- Die Wegpunkte müssen im Voraus per Hand erstellt werden und werden nicht - falls sie noch nicht vorhanden sind - bei der Zuweisung einer Koordinate einfach neu erstellt (würde etwas Vorbereitungszeit ersparen und den Solver auch Adhoc nutzbarer machen)

- Die Nachkommastellen einer Koordinate sollten immer dreistellig sein. Wenn nur einen zweistellige Zahl rauskommt läuft man meist eine ganze Weile in die falsche Richtung. Wie ich oben irgendwo gesehen habe, sollte sich das aber mit :000: und richtiger Klammersetzung korrigieren lassen :)
 
OP
MiK

MiK

Geoguru
lahmer schrieb:
- Die Wegpunkte müssen im Voraus per Hand erstellt werden und werden nicht - falls sie noch nicht vorhanden sind - bei der Zuweisung einer Koordinate einfach neu erstellt (würde etwas Vorbereitungszeit ersparen und den Solver auch Adhoc nutzbarer machen)

Wenn man die Wegpunkte nicht dauerhaft archivieren möchte, ist es nicht nötig diese anzulegen. Dann sind das einfach nur Variablen die am Ende wieder gelöscht werden.
 
Oben