• 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?

OP
MiK

MiK

Geoguru
thomas_st schrieb:
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.
Die Frage ist, wie die Signatur einer solchen Funktion aussehen müsste, damit man ihr auch genau sagen kann, was passieren soll. Vor allem auch, wenn die Ziffernzahl nicht stimmt.
Wenn ich schon
Code:
A=
B=
C=
D=
dastehen habe muss ich nur noch die Ziffern untereinander eintragen. Das sind zusätzlich auch nur dreimal "Pfeil nach unten". Aber wenn Du einen Aufruf kennst, der einfacher ist, dann fände ich das auch praktisch.
 

lahmer

Geocacher
MiK schrieb:
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.

Genau das würde ich aber gern tun... also die berechneten Wegpunkte auch archivieren ohne sie vorher allerdings schon anlegen zu müssen (nur mit leeren Koordinaten)...
ich hatte mir dazu quasi vorgestellt, dass der Check, ob die Koordinaten leer sind auch mit true zurückkommt, wenn der Wegpunkt gar nicht existiert... in dem Fall müsste dann eben ein neuer Wegpunkt mit den berechneten Koordinaten erzeugt werden... falls der Wegpunkt existiert und die Koordinaten nicht gesetzt sind, würden eben nur die berechneten Koordinaten eingesetzt und in allen anderen Fällen würde nichts getan (da der Vergleich false zurückliefert).
 

thomas_st

Geowizard
MiK schrieb:
Die Frage ist, wie die Signatur einer solchen Funktion aussehen müsste, damit man ihr auch genau sagen kann, was passieren soll. Vor allem auch, wenn die Ziffernzahl nicht stimmt.
Wenn ich schon
Darf ich mal lustig rumspinnen? ;) Meine Idee wäre (ohne zu wissen ob das klappt):
Code:
(ABCD) = 1234;
#wobei jetzt
# A == 1
# B == 2
# u.s.w. wären
Das Überspringen von Stellen könnte man mit einem Platzhalter erreichen (im Beispiel der Punkt - könnte auch ein anderes, sinnvolleres Zeichen sein), z.B.
Code:
(AB.C) = 1234;
# wobei nun
# A == 1
# B == 2
# C == 4
# wäre
Aber wie gesagt, ich weiß nicht ob diese realisierbar ist und eine Lösung für den Fall, das zwei Stellen einer Variable zugewiesen werden müssen, habe ich jetzt auch nicht.

MiK schrieb:
Code:
A=
B=
C=
D=
dastehen habe muss ich nur noch die Ziffern untereinander eintragen. Das sind zusätzlich auch nur dreimal "Pfeil nach unten".
Wenn ich den Multi zu Hause vorbereite (habe ich aber erst ein oder zwei Mal gemacht *duck und weg*) ist das möglich - unterwegs hätte ich mir die Tipparbeit gerne gespart.

Viele Grüße,
Thomas(_st)
 
OP
MiK

MiK

Geoguru
lahmer schrieb:
Genau das würde ich aber gern tun... also die berechneten Wegpunkte auch archivieren ohne sie vorher allerdings schon anlegen zu müssen (nur mit leeren Koordinaten)...
ich hatte mir dazu quasi vorgestellt, dass der Check, ob die Koordinaten leer sind auch mit true zurückkommt, wenn der Wegpunkt gar nicht existiert... in dem Fall müsste dann eben ein neuer Wegpunkt mit den berechneten Koordinaten erzeugt werden... falls der Wegpunkt existiert und die Koordinaten nicht gesetzt sind, würden eben nur die berechneten Koordinaten eingesetzt und in allen anderen Fällen würde nichts getan (da der Vergleich false zurückliefert).
Dazu müsste man erstmal klären, wann eine Zuweisung eines Wertes zu einer Variablen dazu führen soll, dass der Wert als Koordinate zu interpretieren ist und ein Wegpunkt (mit Namen der Variablen) angelegt werden soll. Es soll ja nicht bei jeder (Koordinaten-)zuweisung ein Wegpunkt angelegt werden. Da es keine Typisierung gibt ist das alles sehr schwierig.

Vielleicht könnte man einen seperaten Speicherbefehl einführen. Das entspricht aber wohl auch nicht der Einfachheit, die Dir vorschwebt.

Dazu müsste man also erstmal ein konkretes Konzept ausarbeiten, wann was gespeichert werden soll.
 
OP
MiK

MiK

Geoguru
thomas_st schrieb:
Darf ich mal lustig rumspinnen? ;) Meine Idee wäre (ohne zu wissen ob das klappt):
Code:
(ABCD) = 1234;
#wobei jetzt
# A == 1
# B == 2
# u.s.w. wären
ABCD ist dann aber eine Variable. Wenn dann:
Code:
A B C D = 1234
Ich weiß aber nicht, wie gut damit Tokenizer und Parser zurecht kommen oder ob dafür grundlegendes umgeworfen werden muss. Dazu muss sich skg mal äußern. Grundsätzlich geht mir diese Syntax etwas gegen den Strich. Aber wenn es leicht umzusetzen wäre, hätte ich auch nichts dagegen.
 

lahmer

Geocacher
MiK schrieb:
lahmer schrieb:
Genau das würde ich aber gern tun... also die berechneten Wegpunkte auch archivieren ohne sie vorher allerdings schon anlegen zu müssen (nur mit leeren Koordinaten)...
ich hatte mir dazu quasi vorgestellt, dass der Check, ob die Koordinaten leer sind auch mit true zurückkommt, wenn der Wegpunkt gar nicht existiert... in dem Fall müsste dann eben ein neuer Wegpunkt mit den berechneten Koordinaten erzeugt werden... falls der Wegpunkt existiert und die Koordinaten nicht gesetzt sind, würden eben nur die berechneten Koordinaten eingesetzt und in allen anderen Fällen würde nichts getan (da der Vergleich false zurückliefert).
Dazu müsste man erstmal klären, wann eine Zuweisung eines Wertes zu einer Variablen dazu führen soll, dass der Wert als Koordinate zu interpretieren ist und ein Wegpunkt (mit Namen der Variablen) angelegt werden soll. Es soll ja nicht bei jeder (Koordinaten-)zuweisung ein Wegpunkt angelegt werden. Da es keine Typisierung gibt ist das alles sehr schwierig.

Vielleicht könnte man einen seperaten Speicherbefehl einführen. Das entspricht aber wohl auch nicht der Einfachheit, die Dir vorschwebt.

Dazu müsste man also erstmal ein konkretes Konzept ausarbeiten, wann was gespeichert werden soll.

Hm... guter Einwand... mir würde jetzt auch nur ein weitere Funktion createWP(WP, Coords, Type) einfallen... fände ich immer noch besser als das manuelle Anlegen, ist aber nicht ganz so schick (ich gebs ja zu :) )
 

thomas_st

Geowizard
MiK schrieb:
ABCD ist dann aber eine Variable. Wenn dann:
Code:
A B C D = 1234
Stimmt. Wobei ich den Eindruck habe, dass die Klammer - also
Code:
(A B C D) = 1234;
- das Ganze deutlicher macht.
MiK schrieb:
Ich weiß aber nicht, wie gut damit Tokenizer und Parser zurecht kommen oder ob dafür grundlegendes umgeworfen werden muss.
Das weiß ich natürlich auch nicht - daher mein Hinweis auch "Rumspinnen"
MiK schrieb:
Grundsätzlich geht mir diese Syntax etwas gegen den Strich. Aber wenn es leicht umzusetzen wäre, hätte ich auch nichts dagegen.
Darf ich fragen, was Dir missfällt? Würde die Klammer das Missfallen mildern?

Viele Grüße,
Thomas(_st)
 
OP
MiK

MiK

Geoguru
thomas_st schrieb:
MiK schrieb:
Grundsätzlich geht mir diese Syntax etwas gegen den Strich. Aber wenn es leicht umzusetzen wäre, hätte ich auch nichts dagegen.
Darf ich fragen, was Dir missfällt? Würde die Klammer das Missfallen mildern?
Es geht dabei weniger um das Gefallen, als dass es etwas ist, dass ich eigentlich von keiner Programmiersprache kenne. Aber der Solver trifft da ja auch an anderen Stellen Vereinfachungen, die sonst nicht kennt. Wäre vielleicht nur konsequent, das so zuzulassen. Ist aber wirklich eine Fage, wie stark das gegen die bisherige Auswertung läuft. Ich möchte dafür nicht alles umschmeißen. Warten wir, was skg dazu sagt.
 

greiol

Geoguru
MiK schrieb:
Code:
A B C D = 1234
Ich weiß aber nicht, wie gut damit Tokenizer und Parser zurecht kommen oder ob dafür grundlegendes umgeworfen werden muss. Dazu muss sich skg mal äußern. Grundsätzlich geht mir diese Syntax etwas gegen den Strich. Aber wenn es leicht umzusetzen wäre, hätte ich auch nichts dagegen.
als syntax ist es veilleicht nicht der hammer, aber bevor ich anfange mit
Code:
JZAHL=1873
A=mid(JZAHL,1,1)
B=mid(JZAHL,2,1)
geh ich her, lege
Code:
A=
B=
C=
D=
an und mache die zerlegung von hand. geht eh schneller.
 

schappi

Geocacher
Hallöchen,

ich bin noch sehr neu, was das lösen von multis angeht und habe erst zweimal den Solver versucht zu benutzen (Asche über mein Haupt)...
Aber mir ist aufgefallen, dass man sich erstmal mit der Koordinaten-Berechnung beschäftigen sollte, bevor man über das Zuweisen von Arrays nachdenkt, oder ?
Die allermeisten Multis laufen doch in der Form ab:
A=
B=
C=

N (A+B) (B+C).(A*B*C)
E ...

Vielleicht sollte man ersteinmal versuchen, diese Berechnungs-Klammerfolgen flexibel abbildbar zu machen ? Ein anderes Beispiel wäre es bei diesem Cache:

OP° OB.BDL
P° QR.EGK

OP° OI.SVJ
P° QP.VNM

date (IJ.K0.MN)
OP° OA.CDR
R° F.FHP

Wie kann ich soetwas eingeben, ohne mit lauter Hochkommas oder Klammern arbeiten zu müssen ?
 

snaky

Geowizard
Hallo, ganz kurz:

schappi schrieb:
N (A+B) (B+C).(A*B*C)
E ...

"N "(A+B) " "(B+C) "."(A*B*C) "E ..."

OP° OB.BDL
P° QR.EGK
...

"N "O P "° "O B "."B D L
"E "P "° "Q R "."E G K

Geht eigentlich ganz flott. Am besten man kopiert und fügt noch schnell die Anführungszeichen und Space ein. Wenn's noch einfacher geht, lasse ich mich gerne belehren. :)
 

greiol

Geoguru
so wie ich das verstanden habe als
Code:
O P" "O B"."B D L
man beachte dabei die leerzeichen. es muss nur etwas herauskommen was zum parser passt.

in der "guten alten zeit" musste man sogar noch
Code:
show(O)show(P)"° "show(O)show(B)"."show(B)show(D)show(L)
schreiben. der neue solver ist da schon deutlich angenehmer
 

schappi

Geocacher
Das ist mir ehrlich gesagt zu viel Geschäft :-( tut mir leid, wenn ich jetzt die User-Sau raushängen lasse, ist auch nicht bös gemeint - der Solver ist ein hartes Stück programmierkunst.

Nur da findet sich doch immer irgendwo nen Zettel, den man bekritzeln kann... Ich muss bei meinem PDA schon viel tippen, um die Anführungszeichen an die richtigen Stelle zu bekommen..
 

snaky

Geowizard
:shock:
Also ich brauche beim ersten Beispiel weniger als 30 Sekunden. Wenn das schon zu viel ist, dann ist der Solver vermutlich allgemein nichts für Dich.

Ich finde es praktisch, an einem Regentag einen Multi vorzubereiten um dann im Feld das Rechnen sparen zu können.

Ich habe jetzt schon mehrere Caches so gemacht und vor allem spart man sich auch die Umwege durch falsch/verrechnen. Auch evtl. Probleme mit der Fragestellung lassen sich so vorher klären. Besser als wenn man vor Ort steht und nicht weiß, was gemeint ist.
 
OP
MiK

MiK

Geoguru
Eigentlich ist die Idee ja auch, sowas vorher daheim vorzubereiten. Und am PC ist das gar nicht mehr so kompliziert einzugeben. Aber auch das sollte natürlich möglichst einfach gehen. Und manchmal kommt man auch nicht drumrum sowas erst im Feld zu machen.

Um die Leerzeichen kommen wir aber nicht drumrum. Es gibt ja auch Variablen mit mehr als einem Zeichen.

Die frage ist jetzt: gibt es einen konsisten umsetzbaren Weg um noch ein paar Anführungszeichen zu sparen? Entweder im Solver oder in der Regex.

Ideen?
 

snaky

Geowizard
Hmm... vielleicht automatisch von
49 53565 in
49 53.565 umwandeln?

Dann spart man sich das Einfrickeln des Punktes. Kann aber zu Verwechslungen führen, wenn jemand statt eines Punktes ein Space macht (bei d,dddd° Angaben).
 

salzkammergut

Geomaster
Ich habe versucht die Syntax des alten Solvers ohne sie komplett zu verwerfen auf minimale Tipparbeit zu trimmen (daher ist zum Beispiel der "show" Befehl jetzt redundant). Auch der Parser für Koordinaten verarbeitet sehr viele Formate um die Tipparbeit zu minimieren. So ist z.B. in oben angeführtem Beispiel

"N "O P "° "O B "."B D L
"E "P "° "Q R "."E G K

das Gradzeichen nicht notwendig. Ein Leerzeichen zwischen Grad und Minuten ist aber unumgänglich, so ist

"N"O P " "O B "."B D L
"E"P " "Q R "."E G K

Die Minimalvariante. Das ist auch relativ leicht zu merken ohne groß irgendwo nachschlagen zu müssen. Ich habe keine Idee wie das noch einfacher geschrieben werden soll.

Zum Thema Mehrfachzuweisungen a la

Code:
A B C D = 1234   oder
(A B C D) = 1234

Macht die Sache natürlich komplizierter, da der Parser erst beim "=" weiß, daß der Ausdruck A B C D nicht auszuwerten ist (Da hat er ihn aber schon ausgewertet bzw. einen Fehler erzeugt, da A keinen Wert hat). Da der Parser ein ganz einfacher (rekursive descent) Parser ist, hat er nur einen Lookahead von 1, daß heißt er nutzt nur das nächste Symbol um zu entscheiden wie er weiter vorgehen soll. Müßte aber mit ein paar Hacks machbar sein (mit einem erweiterten Lookahead). [Tschuldigung für diesen technischen Exkurs.]

Wenn das gewünscht wird werd ich mir das mal anschauen mit einer Syntax wie oben angeführt (wohl ohne Klammer, ein Punkt ist für eine Stelle die nicht zugewiesen werden soll) also beispielsweise:
Code:
A . FF = 123

Der Befehl
Code:
A . FF = 1234
erzeugt einen Fehler, da auf der rechten Seite zu viele Ziffern stehen, bzw. auf der linken Seite zuwenige Variable. OK?

Grüße
skg
 

greiol

Geoguru
salzkammergut schrieb:
Macht die Sache natürlich komplizierter, da der Parser erst beim "=" weiß, daß der Ausdruck A B C D nicht auszuwerten ist (Da hat er ihn aber schon ausgewertet bzw.
wir brauchen also ganz klar einen multi pass parser mit zwischengeschaltetem p-code oder so.
vielleicht wird cw am ende so eine art emacs für geocaching ;)
 
greiol schrieb:
wir brauchen also ganz klar einen multi pass parser mit zwischengeschaltetem p-code oder so.
vielleicht wird cw am ende so eine art emacs für geocaching ;)
multipass.gif


EMACS für’s cachen?
Cachewolf wird also ein Betriebssystem?
 
OP
MiK

MiK

Geoguru
salzkammergut schrieb:
Der Befehl
Code:
A . FF = 1234
erzeugt einen Fehler, da auf der rechten Seite zu viele Ziffern stehen, bzw. auf der linken Seite zuwenige Variable. OK?
Man könnte auch den Rest immer der letzten Variablen zuweisen. Aber wahrscheinlich will man eher eine Fehlermeldung haben. Meinungen?
 
Oben