Hallo, ich möchte in einem JS den quadratischen Mittelwert von 12.000 Daten ausrechnen und benutze unter anderem Math.pow(Wert, 2). Beim Summieren kommt dabei leider sehr schnell nAn (Not a number) raus. Es handelt sich um auch tatsächlich um ursprüngliche long long-Daten. Selbst wenn ich die Daten mit Faktor 0.00001 verkleinere und nach der Berechnung mit 100000 zurückhole, kommt nAn raus
long long meint 64 Bit Integers? (2^64)^2*12000 = 4E42 JS Number.MAX_VALUE = 1.8E308 Sollte sich locker ausgehen. Ich schätze da gibt's einen Coding- oder Datenfehler, aber das hast du ja nicht gezeigt.
Dein Problem ist wahrscheinlich nicht die Addition der Werte sondern liegt weiter vorne. Wie liest du die Daten ein? Kommen die aus einem JSON oder einem anderen String basierten Format? Sind das 64 bit Integer-Zahlen in einem Int64 Array oder als String? Damit kann Javascript nicht wirklich gut umgehen, wenn du einen Genauigkeitsverlust vermeiden willst, dann musst du diese als BigInt hantieren, d.h. vom String selbst in einen BigInt konvertieren. > let a=BigInt("123456789012345678901234567890") > let b=a*a > b 15241578753238836750495351562536198787501905199875019052100n Sind es Floating Point Werte? Falls ja mit Punkt oder Komma als Dezimal-Separator? Mit "," als Separator kommt NaN raus oder wenn noch was dahintersteht: > Number("1,23") NaN > Number("123x") NaN > Number("123e") NaN > Number("123.5e3") 123500 Michael
:
Bearbeitet durch User
Bringt der Link hier was beim Hantieren mit größeren Zahlenwerten? https://github.com/peterolson/BigInteger.js Stackoverflow-Seiten können zu verschiedenen Thematiken hilfreich sein: https://stackoverflow.com/questions/1458633/how-to-deal-with-floating-point-number-precision-in-javascript bigInt() will muss man wohl erst importieren: https://www.delftstack.com/de/howto/javascript/javascript-square-a-number/
DPA schrieb: > https://jsfiddle.net/4kLtf5y9/1/ Aber das ganze Bigint - Gewurschtel braucht's vermutlich garnicht. Das Problem vom TE arbeitet ja nur auf relativ kleinen Zahlen, selbst im Absoluten Worst-Case ist er noch meilenweit vom Number.MAX_VALUE entfernt. d.H. dass sein NaN von einem Overflow kommt, ist komplett ausgeschlossen. allerdings verlässt er den Number.MAX_SAFE_INTEGER - Bereich, d.H. es gibt Rundungsfehler wg. Floating-Point. Das könnte man durch eine verbesserte Aufsummier-Reihenfolge optimieren.
Εrnst B. schrieb: > Aber das ganze Bigint - Gewurschtel braucht's vermutlich garnicht. Das "vermutlich" ist das Problem hier. Der TO "daniel12" hat sich seit 3 Tagen nicht gemeldet und keinerlei Details rausgelassen oder auch nur einen Hinweis, dass sich sein Problem in Luft aufgelöst hat. Sollte "DPA" mit "daniel12" identisch sein, so kann ich das nicht erkennen. > Das Problem vom TE arbeitet ja nur auf relativ kleinen Zahlen, Ich konnte keinen Hinweis vom TO auf die konkreten Zahlen finden, außer folgendem: "long long-Daten" Michael
:
Bearbeitet durch User
Michael D. schrieb: > Ich konnte keinen Hinweis vom TO auf die konkreten Zahlen finden, außer > folgendem: "long long-Daten" Eben, das wären dann maximal 2^64 (unsigned), also >> 18446744073709551616 pro Wert. Davon das Quadrat wäre maximal >> 340282366920938463463374607431768211456 das mal 12000 für seine Summe ist >> 4083388403051261561560495289181218537472000 also läppische 4*10^42 für den absoluten Worst-Case Die Javascript-Zahlen laufen erst bei 10^308 über. deshalb: "relativ klein".
Man sollte dem TO einen Abakus als Arbeitsmittel empfehlen. Der kennt prinzipbedingt keinen Überlauf. Genau die richtige Strafe für diese Javascriptfickler.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.