Funktionsweise Solver v.2

[klausundelke]

gezielt: Link aus dem Betreff des Beitrags.

Funktioniert! Wieder was gelernt, danke!

Wäre trotzdem schön, wenn es gleich im Wiki wäre.

Natürlich....

Ich gehe mal davon aus, dass die beiden Buttons dort nicht erklärt sind.

Sonst hätt ich nicht gefragt...

Da kann dann nun nur der Programmierer weiterhelfen (oder ein Blick ins Programm)

Nachdem ich vermutlich schon nicht mal die richtige Stelle im Code finden würde geschweige denn damit was anfangen könnte wart ich mal ab ob sich ein "Verantwortlicher" meldet...

 

[arbor95]

So, habe mal ins Prog geschaut:
Die 3 Tasten bewirken noch nichts.
Folgendes ist anscheinend vorgesehen:
mit dem @ soll eine Variablenliste eingeblendet werden.
mit dem +/- soll eine Liste von Operatoren eingeblendet werden.
mit dem GC soll eine Liste von Wegpunkten eingeblendet werden.

 

[klausundelke]

Super, danke für die Aufklärung. Brauch also nicht weiter probieren warum nix passiert wenn man die Buttons drückt.

 

[Saturo]

Ich habe heute mal wieder etwas ausführlicher getestet.
Folgendes ist mir dabei aufgefallen.

Das Aufrufen von Wegpunkten mittels Button ist sehr nützlich. Leider lassen sich die Wegpunkte, Variablen etc. nur in das untere Formelfeld einfügen. Für Formeln ist dies auch Okay. Variablen und Wegpunkte gehören meiner Meinung nach jedoch in das Eingabefeld vor dem =
Beispiel:

"N50 49."... "E010 49."...
=
$AB1234

Das Problem hierbei ist, das zumindest der Solver 1 erwartet, dass links immer die Variable steht.

Richtig wäre also
$AB1234
=
"N50 49."... "E010 49."...
Dies lässt sich jedoch momentan mittels Buttons nicht eingeben.

Außerdem ist mir aufgefallen, dass zweistellige Ergebnisse, z.B. 95 momentan als 950 anstatt 095 interpretiert werden, die Null wird also hinten statt vorne angehangen.

Diese Tatsache hat uns heute gut eine Stunde Umweg und das Suchen an einer völlig falschen Stelle eingebracht. Man darf sich halt nicht blind auf den Solver verlassen.

Viele Grüße
Christian

 

[klausundelke]

Außerdem ist mir aufgefallen, dass zweistellige Ergebnisse, z.B. 95 momentan als 950 anstatt 095 interpretiert werden, die Null wird also hinten statt vorne angehangen.

Das ist schon länger bekannt!
Leider gibt es manche Owner nie das genau so voraussetzen, von daher ist das eh problematisch.
Du kannst das erreichen wenn Du in WCB/ACB hinter die Koordinate ein ":3" schreibst:
z.B.
$ABC="N 47 54."4*D:3" E 10 15."4+A:3
dann wird immer auf 3 Stellen gefüllt und zwar von rechts her.

 

[Inder]

Außerdem ist mir aufgefallen, dass zweistellige Ergebnisse, z.B. 95 momentan als 950 anstatt 095 interpretiert werden, die Null wird also hinten statt vorne angehangen.

Das ist schon länger bekannt!

Das ist doch auch korrekt so? Es handelt sich dabei um die Nachkommastellen bei den Minuten.
10,75 ist gleiche 10,750 (und 10,750000000) und nicht gleich 10,075.

 

[klausundelke]

Das ist doch auch korrekt so?

Na ja, es gibt halt einfach beide "Varianten" auf dem Markt
Wichtig ist halt einfach, daß man sich zu helfen weiss wenn man die Variante
mit der führenden 0 vorfindet.

 

[Saturo]

In den aktuellen Versionen fällt mir auf, dass selbst angelegte Variablen nicht erkannt werden.

Beispiel:
C=B+A
A=1
B=2

Liefert missing A,B

Läßt man die Variablen mit dem Solver 1 einfügen werden sie korrekt erkannt.

Gesendet von meinem GT-I9300 mit Tapatalk 2

 

[Longri]

Erst deklarieren, dann benutzen. .!

 

[Saturo]

Oder man nutzt weiterhin den Solver 1 zum einfügen der Variablen.
Ich füge zuerst die zu berechnenden Formeln in den Sover ein und leite dann daraus die Variablen ab.

Gesendet von meinem GT-I9300 mit Tapatalk 2

 

[Wolli]

Hi

mir ist gestern etwas aufgefallen (V1956).
Sind alle Variablen bekannt und das Final steht fest, dann wird der Wegpunkt falsch angelegt.
Statt den Finalkoordinaten werden die Standortkoordinaten angelegt:

Hat mich gestern 20 Minuten meines Lebens gekostet

Gruß Wolli

 

[Longri]

Hat mich gestern 20 Minuten meines Lebens gekostet

Der ausgedruckte Cachebox- Code!

Hat mich zwei Jahre meines Lebens gekostet!

 

[Wolli]

Hi Longri

ja, da hast Du tatsächlich mehr Lebenszeit investiert.

Meine 20 Minuten waren auch nur als Scherz gedacht und nicht als Kritik
Ich habe nach 20 Minuten erfolgloser Suche erst gemerkt, das da was nicht stimmen kann. Hätte auch früher schon draufkommen können, aber weil das bisher immer klappte habe ich mich total auf Cachebox verlassen. Meine mitcachende Frau wurde schon etwas, na ja, sagen wir ungeduldig.

Was will ich damit sagen: Ihr macht einen tollen Job und ich bin froh das ich Cachebox habe, für mich immer noch das beste Programm zum cachen.

Gruß Wolli

 

[Koblenzer]

Der ausgedruckte Cachebox- Code!

Krass, ein Papier Backup?

 

[Longri]

Es war auch von mir nicht ganz so ernst gemeint. Ich mach es ja gerne.
Ich bin nur gerade ein wenig frustriert, mit der Performance von Mapsforge. Aber irgendwann wird alles gut.

 

[arbor95]

Aber mit wollis code wird doch gar kein wegpunkt angelegt!!!!!

Vielleicht liegt da der Denkfehler!

Wenn du dich fragst, warum der Final auf einmal Koordinaten hat, wo doch vorher mal 0 0 oder so drin stand, dann ist das eine Auswirkung meiner Schreibfaulheit : ich wollte mir die manuelle Eingabe 48 Grad bzw 9 Grad sparen.!

Natürlich würde dabei kein $WEGPunkt=xxxxx überschrieben!

 

[cacheboxer]

Das Phänomen, dass der Wegpunkt aus dem Solver machmal mit den Startkoordinaten belegt wird (machmal auch mit 0° 0.000'), habe ich auch manchmal. Ich vermute, dass er das macht, wenn er die Formel nicht korrekt als Koordinate interpretieren kann.

Wollis Beispiel verstehe ich aber nicht - einen Wegpunkt kann man nur anlegen, wenn die ganze Koordinate auf einer Zeile steht - im Beispiel gibt es eine Zeile für Nord und eine für Ost?!?

 

[arbor95]

Ich meinte etwas anderes:
Wenn Koordinate eingeben (oder ändern für Koordinaten 0 ) aufgerufen wird, dann passiert eine Vorbesetzung mit sinnvollen Koordianten (GPS).

Vermutlich hatte Wolli gemeint, sein Solvercode hätte Koordinaten geschrieben. Dabei war es die Vorbesetzung.

 

[Homer-S]

@Wolli:

machst du es immer so, dass Nord und Ost Teil in unterschiedlichen Feldern stehen?
Funktioniert das sonst?

Ich frage so dumm, weil bei WCB MUSS die Zeile so aussehen

"N48 12.123 E12 34.345"

So sieht es dann auch bei mir im ACB aus besonders Solver1 ergibt genau das gleiche Erscheinungsbild und wird als ein Feld im Solver2 angezeigt und dann klappt das bei mir auch gut ...

@Longri: lass dich nicht von dem Mapsforge Code ärgern ...

 

[Ging-Buh]

Hi

mir ist gestern etwas aufgefallen (V1956).
Sind alle Variablen bekannt und das Final steht fest, dann wird der Wegpunkt falsch angelegt.
Statt den Finalkoordinaten werden die Standortkoordinaten angelegt:

Hi Wolli,

ich denke ich weiß warum ACB bei dir die Final-Koordinaten nicht übernommen hat.
Wenn du bei deiner markierten Zeile genauer hinschaust dann siehst du dass du zwischen "39." und "408" eine Leerstelle stehen hast. Dies dürfte für ACB der Grund sein dass die Koordinate nicht richtig geparst werden konnte und der Koordinaten Dialog deshalb mit den falschen Koordinaten gefüllt wird.

Da ist ACB pingeliger wie es sein müsste und das könnte sicherlich noch verbessert werden, für den aktuellen Stand dürfte dies aber die Erklärung sein.

Ich werde mal schauen was wir hier tun können.
Einerseits sollte sicherlich die Routine zum Parsen der Koordinate toleranter gemacht werden, andererseits sollte der Solver aber auch eine Meldung ausgeben wenn eine Koordinate nicht verstanden wird.

@Wolli:

machst du es immer so, dass Nord und Ost Teil in unterschiedlichen Feldern stehen?
Funktioniert das sonst?

Ich frage so dumm, weil bei WCB MUSS die Zeile so aussehen

"N48 12.123 E12 34.345"

Keine Angst, eine Frage kann selten zu dumm sein.
Der Solver2 ist aber tatsächlich so "intelligent" dass er entweder komplette Koordinaten aus einer Zeile ausliest oder Koordinaten aus 2 aufeinanderfolgenden Zeilen zusammensetzt. Dazu muss dann die obere der beiden Zeilen markiert sein.