Nachkommastellen

[t31]

bei AB=23 wäre 48.AB richtigerweise 48.23, alles andere ist falsch und bedarf Kritik im Log und zwar solange bis auch der letzte Owner das verstanden hat.

Natürlich kann man sich mit :000: behelfen damit 48.023 herauskommt falls der Owner mal wieder gepennt hat, aber was ist, wenn er es richtig gemacht hat und wirklich 48.23 meint?

Man kann hier nur eines machen: immer die Zwischenkoordinaten ausgeben und nachprüfen ob sie plausibel sind, was natürlich bei einer nachfolgenden Peilung schwer wird, weil da könnte theoretisch der Ausgangspunkt auch im See liegen. Bei meinem letztem Cache mit diesem Problem wäre ich im Ausland gelandet, so das ich nochmal schaute was mit vorangestellte Null passieren würde, was letztlich auch gut und richtig war. Danach wurde es gleich im Log thematisiert und siehe da, auch die nachfolgenden Cacher wissen auf den bis dahin nicht erwähnten Fehler hin. Muß gleich mal schauen ob der Owner reagiert hat.

 

[MiK]

@Wutschkow: Beim Koordinatenparser lassen sich die drei Nachkommastellen leicht erzwingen. Das ist sofort geändert.

Es soll also wirklich eine nervige Meldung kommen, nur weil ich bei Koordinaten nur 2 Nachkommastellen eingebe?

 

[salzkammergut]

@Mik: Ich habe mich vielleicht mißverständlich ausgedrückt: Ich meinte dass es leicht geändert werden könnte, aber nicht dass ich es ändern werde.

skg

 

[Wutschkow]

Klar geht es hier darum, mit Problemen umzugehen, die man bei perfekten Cachebeschreibung nicht haben dürfte. Andererseits gibt es ja Owner die ausdrücklich schreiben, "wenn man nur zwei Ziffern hat, muss eine 0 vorangestellt werden" oder eben "wenn man nur zwei Ziffern hat, muss eine 0 drangehängt werden".
Wenn ein Owner sich über sowas gar nicht erst Gedanken macht oder es beim Testen nicht bemerkt, kann Cachewolf auch nicht helfen. Da muss man eben selbst aufpassen.

Was man höchstens machen könnte: Anstatt ":000:" jedesmal hinzuschreiben, kann man diese "Maske" global für ein Solverskript setzen. Also ganz am Anfang schreiben zeroMask("0XX") oder zeroMask("XX0"). Das gilt dann für den Rest des Skripts und wird immer benutzt, wenn bei einer Koordinatenübergabe (also bei goto, center, project usw.) eine Koordinate mit zuwenig Nachkommastellen übergeben werden sollte.

So ließen sich Vorgaben von Owner - so es denn welche gibt - einfach umsetzen.

 

[t31]

@ Wutschkow

Ich hätte da immer noch Bauchschmerzen. Händisch ist mir das jedenfalls lieber, weil wenn es im Listing erwähnt wird (führende Null), kann ich selbst mit der Formatierung :000: dies sicherstellen. In den meisten Fällen ist es unklar und man muß - so ärgerlich das ist - vor Ort schauen was passt bzw. abgehen oder zuvor den Owner kontaktieren wenn man es bereits daheim merkt das möglicherweise das Problem auftauchen kann.

Ich weiß jetzt nicht wie intern die Koordinaten gehändelt werden, theoretisch könnte ja dabei auch ein zweistelligen Nachkommataereignis auftreten, dann wäre es fatal wenn durch die globale Definition eine Null eingeschoben wird.

 

[MiK]

Intern werden Koordinaten als Dezimalgrad behandelt. Soetwas könnte also nur bei der Wandlung von einem String in eine Koordinate passieren.

 

[Wutschkow]

wenn es im Listing erwähnt wird (führende Null), kann ich selbst mit der Formatierung :000: dies sicherstellen

Ja, dass man das kann, hatten wir ja schon festgestellt. Aber wenn ich einen längeren Multi zu Hause vorbereite (wofür der Solver ja wohl im wesentlichen gedacht ist), weiß ich ja nicht, an welchen Stellen ich diese Formatierung benötige. Also muss ich sie auf Verdacht an allen möglichen Stellen einfügen, was je nach Anzahl der Stationen recht aufwändig sein kann. Ein zentraler Switch, der das Standardverhalten (für diesen Cache) entsprechend abändert, wäre weitaus komfortabler.

Ich sage ja nicht mal, dass das nun besonders dringend wäre. Es wäre einfach nice to have, weil es in manchen (gelegentlichen) Situationen den Umgang mit Cachewolf einfacher machen würde. Und die Umsetzung wäre nicht besonders aufwändig, behaupte ich jetzt einfach mal, ohne mir den Solver-Code allerdings jemals ernsthaft angeschaut zu haben.

 

[Wutschkow]

Es soll also wirklich eine nervige Meldung kommen, nur weil ich bei Koordinaten nur 2 Nachkommastellen eingebe?

Wäre ein akustisches Signal - z. B. ein kurzes "Pling" so wie wenn man im GoTo-Panel das Zentrum neu setzt - auch zu nervig? Mir würde das als Hinweis reichen, dass da irgendwas außergwöhnliches war und ich lieber noch mal hinschauen sollte.
Wobei der Parser die 0 nicht nur oben bei den ermittelten Koordinaten ergänzt, sondern auch unten im Eingabefeld, wenn ich das recht im Kopf habe. Das macht die Kontrolle nicht gerade einfacher.

Deshalb mein Vorschlag: Wenn beim Parsen eine 0 ergänzt wird, einmal kurz einen akustischen Hinweis und am ursprünglichen Eingabefeld nichts verändern, nur die endgültigen Koordinaten korrigieren.
Dann kann man vorher-nachher vergleichen und sieht sofort was gelaufen ist und kann es so lassen oder ändern.

 

[pfeffer]

ich wäre für ne richtige Meldung.

Gruß,
Pfeffer.

 

[Robin888]

Also ich habe schon jede Menge Multis im Solver vorbereitet und muß sagen, daß ich *damit* noch keine großen Probleme hatte.

Erstens hatte ich noch *keine* Formel in der 48.A (mit A=21) 48.210 bedeuten sollte.

Zweitens werden (bei Verwendung des skeleton-Befehls) die Koordinaten mit ausgegeben was einem die Gelegenheit gibt kurz zu schauen, ob Nullen vorkommen und entsprechend wachsam zu sein.

Drittens bereite ich (längere) Multis nicht im Solverfenster vor, sondern in einem anständigen Texteditor! Mit Festbreitenschrift und Undo-Funktion (und vielem mehr).
Da könnte man sicherlich ein kleines Makro schreiben, daß einem die ":000:" automatisch einfügt.

Und viertens denke ich auch, daß eine Funktion wie sie hier besprochen wird zuviel versucht "mitzudenken". Von den Problemen der Umsetzung abgesehen würde ich sowas gar nicht wollen. Sonst kann ich irgendwann *gar* nicht mehr nachvollziehen wieso ein Problem auftritt oder wie ich es beheben kann.

Robin(888)

 

[greiol]

die meisten owner sind je vernünftig. aber vor zwei monaten hatte ich einen cache bei dem ich bei den stationen 1 bis 3 den spass hatte, dass statt xx0 jeweils 0xx richtig gewesen wäre. als bei station 4 dann yy0 raus kam war ich mir sicher nicht nochmal drauf rein zu fallen und bin zu 0yy gegangen. die 4. station war aber dann doch bei yy0

ein entsprechender kommentar im log hat allerdings bisher zu keiner änderunge geführt.

 

[Engywuck]

Ich warte noch auf den ersten Cache, der Punkt- vor Strichrechnung konsequent ignoriert... Bislang ist mir sowas glücklicherweise noch nicht untergekommen.

Gruß,
E.

 

[MiK]

Wie man aus der Beschreibung noch deutlich entnehmen kann, war dieser mal so:
http://www.geocaching.com/seek/cache_details.aspx?guid=9cb5ce40-11f0-4147-abf5-a4f151041741

 

[pfeffer]

wie wäre es, wenn in dem Ausgabefenster einfach eine Warnung erscheint "Minuten wurden mit weniger als 3 Stellen hinter dem Komma angegeben"

Gruß,
Pfeffer.

 

[Wutschkow]

Die Klammern in der Formel sollen lediglich die Mathematik-Fanatiker ruhig stellen!

Man kann die Klammern auch ignorieren, wenn man dann die Punkt-Vor-Strich-Regel außer Acht lässt!

Klasse!
Was ist das? Mathematik für Bildungsferne?

Könnte man ja auch mal bei einer Fahrprüfung probieren:
"Wieso durchgefallen? Man kann die rote Ampel auch ignorieren, wenn man dann die Rechts-vor-Links-Regel außer Acht lässt."

Danke für die Aufheiterung!

PS: Sorry für offtopic

 

[Engywuck]

Ich interpretiere die Sichtweise des Autors mal als:
"Klammern und Punkt-Vor-Strich-Rechnung sind höherer mathematischer Nonsens, die ich hier (wie jeder Mensch, der seine Sinne einigermaßen beisammen hat) einfach ignoriere. Schließlich ist es doch selbstverständlich, dass Rechnungen von links nach rechts durchgeführt werden - zumindest wenn man nicht promovierter Mathematiker ist. Da es dennoch einige Deppen zu geben scheint, die auf diesen Kokolores voll abfahren, schreib ich die Klammern einfach mal hin. Ich verstehe sie zwar nicht, aber so bekomme ich zumindest weniger Zuschriften zu dem Thema..."

 

[pfeffer]

jaja und wir sind alles tolle Hengste, die sich in allen Gebieten perfekt auskennen...

Vielleicht wieder zurück zum Thema?

Was haltet Ihr von meinem Vorschlag, einer Warunung im Ausgabefenster?

Gruß,
Pfeffer.

 

[Wutschkow]

Was haltet Ihr von meinem Vorschlag, einer Warunung im Ausgabefenster

Das wäre sicherlich ein Schritt in die richtige Richtung. Am besten möglichst knapp gehalten, denn im Ausgabefenster ist der Platz bei mir meistens knapp.

Wäre natürlich blöde, wenn nach der Stelle, welche die Warnung ausgelöst hat, noch was kommt, was weiteren Text ins Ausgabefenster schreibt. Dann scrollt die Warnung nach oben weg, oder?

 

[greiol]

also ich fände es gut wenn darauf hingewiesen würde. ob mit einer extra warnung, oder z.b. dadurch dass die koordinaten in rot statt in schwarz geschrieben werden, ist mir dabei nicht ganz so wichtig.

 

[Engywuck]

also ich fände es gut wenn darauf hingewiesen würde. ob mit einer extra warnung, oder z.b. dadurch dass die koordinaten in rot statt in schwarz geschrieben werden, ist mir dabei nicht ganz so wichtig.

Das schreiben von Koordinaten hilft nicht immer:

X="N 50° 14."A B" E 6° 39."C D
Y=project(X, 14, 14)
"Nächstes Ziel bei: "Y

Hier merkt man erst bei der Berechnung der project-Funktion, dass eine Koordinate benötigt wird. Die möglicherweise fehlerhafte Koordinate wird aber nirgenswo ausgegeben.

Gruß,
E.