JS parsed je nach Browser Float anders?!

[Matrix316]

Also ich habe eine String Zahl:

9.151520133018493

Wenn ich im Internet Explorer parsefloat() mache, kommt

9.151520133018493

raus.

Wenn ich im Firefox oder Chrome parsefloat() mache, kommt

9.151520133018494

raus.

Kann man hier auch direkt testen:

http://www.mediaevent.de/javascript/Javascript-Funktionen.html

Einfach mal die erste Zahl oben eingeben. Bei unterschiedlichen letzten Zahlen kommen auch teilweise unterschiedliche Ergebnisse. Eine 4 am Ende interpretiert Firefox z.B. als 4 und IE macht ne 3 draus.

Das ist natürlich ganz toll, wenn ich mit exakt dieser Zahl in der Datenbank einen Wert rausfinden will. Wie kann man das umgehen? Gibts was anderes noch als parseFloat in Javascript?

[Matrix316]

Ok, hab rausgefunden: das ist halt so. Nehm ich halt die letzte Stelle immer weg. Dann gehts.:rolleyes:

[Ganon]

Was denn für ne Datenbank? Und warum lässt du nicht die Datenbank die Wandlung übernehmen, wenn es so genau sein muss?

[Trap]

Es gibt ja auch keine 64-bit Fließkommazahl mit dem exakten Wert
9.151520133018493

Mit http://babbage.cs.qc.edu/IEEE-754/Decimal.html kann man die Fließkommazahlen nach IEEE-Standard anzeigen lassen. Es gibt da nur
9.151520133018492
9.151520133018494
dazwischen gibt es keine Zahl.

[Matrix316]

Datenbank ist MSSQL Server und irgendwie muss ich die Daten ja reinbekommen, aber die Datentypen in der Anwendung kürzen schon munter drauf los. Scheiß 64 Bit Datentyp...;)

Ich könnte es ja einfach als varchar speichern, was ich aber net soll, da man nach und mit varchar nicht so einfach suchen und rechnen kann. Naja, was solls. Jetzt gehts.

[Coda]

Es ist generell fast immer eine schlechte Idee FP-Werte direkt zu vergleichen.

Ich bin mir auch ziemlich sicher, dass es Fälle gibt in denen es nicht genügt einfach die letze Stelle der Dezimalrepräsentation wegzulassen. Das ist ein schlechter Hack.

Wir müssten aber mehr über die Anwendung wissen um dir da einen guten Ratschlag geben zu können.

[Gast]

Das ist natürlich ganz toll, wenn ich mit exakt dieser Zahl in der Datenbank einen Wert rausfinden will.
Wenn du Gleitkommazahlen auf Gleichheit vergleichen willst, machst du etwas grundsätzlich falsch!

Wahrscheinlich lässt sich dein Problem ganz leicht durch die Verwendung rationaler Zahlen mit fixem Nenner lösen. Dann kannst du den Zähler einfach als Integer speichern und dann klappt auch der Vergleich auf Gleichheit.

[Trap]

Wenn du Gleitkommazahlen auf Gleichheit vergleichen willst, machst du etwas grundsätzlich falsch!
Wenn man nicht weiß welche Fließkommazahlen es überhaupt gibt auf jeden Fall.

Bei entsprechenden Kenntnissen könnte es ab und zu mal sinnvoll sein.

[Gast]

Bei entsprechenden Kenntnissen könnte es ab und zu mal sinnvoll sein.
Nein, eigentlich nicht.
Wenn überhaupt sollte man den Umweg über abs(float1-float2)<epsilon gehen. Je nach Anwendungsfall auch die normierte Variante davon.

[Matrix316]

In der Datenbank stehen eigentlich garkeine float Werte, sondern nur noch BigInt.

Google liefert mir aber als Geokoordinaten Float Werte. Die nehmen wir mit Faktor x, damit wir keine Nachkommastellen mehr haben.

So, aber für Google Maps (in der Anwendung) brauchen wir halt wieder die float Werte, also müssen wir den BigInt Wert mit dem Faktor teilen. So weit so gut, nur irgendwann macht die google maps api aus dem richtigen Float Wert einen falschen, weil irgendwann parseFloat mit dem Wert gemacht wird und dann stimmt die letzte Nachkommastelle net mehr. Das ist für Google Maps unerheblich, aber wenn ich den Wert, der der Marker vorher bekam wieder auslese und dann mit meinem Faktor auf int umrechne, ist der halt nicht mehr der gleiche Wert der vorher in der DB gespeichert wird. Wir vergleichen also die beiden Integer Werte miteinander, jedoch durch umrechnung ist eine Stelle falsch.

Das mit der Differenzabfrage ist aber eine gute Idee und wenn ich dazu komme, probier ichs mal aus. :)

Also was eigentlich gemacht wird: Ich wähle einen Punkt auf einer Google Maps Karte aus. Speichere dann die Lat/Lng Werte in der Datenbank (mit weiteren Daten zu dem Ort). Die Geodaten werden vorher mit Faktor X multipliziert um die Nachkommastellen wegzukriegen. Dann irgendwann lesen wir die Werte aus der DB und setzen automatisch Marker auf der Karte für die jeweiligen Werte. Wenn ich dann einen Marker auswähle, kuck ich in der DB mit den Lat/Lng Werten um den Ort rauszufinden. Mehr isses net.

[Gast]

Wenn ich dann einen Marker auswähle, kuck ich in der DB mit den Lat/Lng Werten um den Ort rauszufinden.
:ugly:

Das hört sich nach einem Designfehler an. Warum bekommt der Marker nicht einfach eine id verpasst, die ihn sowohl auf der Karte als auch in der Datenbank eindeutig identifiziert. Was macht denn euer aktuelles System wenn ich zwei Marker an die gleiche Stelle setze?

[Matrix316]

:ugly:

Das hört sich nach einem Designfehler an. Warum bekommt der Marker nicht einfach eine id verpasst, die ihn sowohl auf der Karte als auch in der Datenbank eindeutig identifiziert. Was macht denn euer aktuelles System wenn ich zwei Marker an die gleiche Stelle setze?
Das geht net per Definition. ;)

Und warum ich net die ID nehme... keine Ahnung. Eigentlich wäre das ja logisch, aber vielleicht gabs ein Problem irgendwie... muss ich mal nachkucken. :redface:

PS.: jaaaaaaaaaaa... ich depp hab zwei hidden fields mit ähnlichem Namen und dem einen hab ich beim click die ID zugewiesen und den anderen abgefragt, so dass da nie was übergeben wurde... jo mit ID gehts auch. ;) THX!

[Tommes]

Wieso speichert ihr die Float-Werte nicht so wie sie kommen in der Datenbank?

[Matrix316]

Wieso speichert ihr die Float-Werte nicht so wie sie kommen in der Datenbank?
Sie kommen ja mit 15 Nachkommastellen... und dann gibts Rundungsfehler, beim Auslesen aus der Datenbank. Alles schon probiert. ;)

[Tommes]

Sind das die Geo-Koordinaten, die von der Google API kommen? Die haben ich immer direkt in der Datenbank (MySQL) gespeichert und hatte nie Probleme. Ich habe die Daten als Varchar gespeichert - probier das doch mal. Allerdings habe ich auch solche Werte bekommen: 46.4534150,6.8564590 und keine 15 Nachkommastellen.

[Matrix316]

Ich soll aber net die Werte als varchar abspeichern. Frag nicht. Ist so. ;)

Also wenn ich direkt auf die Karte klicke, bekomme ich die vielen Nachkommastellen....

[Misda]

Dann speicher die Werte doch als DECIMAL ab -> http://dev.mysql.com/doc/refman/5.1/de/precision-math-decimal-changes.html

Da gibts auch garantiert keine Rundungsfehler beim Auslesen.

[Pinoccio]

Sie kommen ja mit 15 Nachkommastellen...Hm, bei Google Earth ist nach der 6ten Stelle Schluß (<=11,132 cm), mehr ist doch nun auch nicht unbedingt sinnvoll.

mfg

[DanMan]

Dann speicher die Werte doch als DECIMAL ab -> http://dev.mysql.com/doc/refman/5.1/de/precision-math-decimal-changes.html

Da gibts auch garantiert keine Rundungsfehler beim Auslesen.
Er will wohl irgendwas im Javascript rumrechnen, und da gibts eben keine echten Dezimalzahlen, weil intern mit binären Gleitkommazahlen gerechnet wird.

[Ectoplasma]

Ich soll aber net die Werte als varchar abspeichern. Frag nicht. Ist so. ;)

Also wenn ich direkt auf die Karte klicke, bekomme ich die vielen Nachkommastellen....

Naja, die Frage ist doch, was du sonst noch mit den Geodaten anfangen willst? Etwas als Float oder Double zu speichern ist nur so lange gut, solange du etwas damit berechnen möchtest. Zur Abfrage in Datenbanken ist dieser Datentyp jedenfalls denkbar ungeeignet.

Vielleicht findest du ja heraus, wer die Entscheidung getroffen hat und fragst ihn mal direkt.

[Matrix316]

Ich weiß wer das war - mein Chef. ;) Er meinte nur, mit Varchar, kann man schlecht rechnen und jeder cast kostet ja auch irgendwie Performance.

Bei Google Earth sinds vielleicht nur 6, aber bei Google Maps 15 Nachkommastellen. Die latlng.x bzw. y Werte sind so ausführlich, und klar, reichen auch weniger, aber es wird halt auch ungenauer.

[Tommes]

Du benutzt die Werte aus der Datenbank doch um damit via JavaScript Pins anzuzeigen, oder? Und dazu schreibst du die Koordinaten doch in den HTML Quelltext oder fragst sie via Webservice o.ä. ab?