Ungewöhnliche Nachkommastellen in der History

[Shark01]

@paul53 Vielen Dank für die Antwort. Verstehe zwar nicht wie diese entstehen. Werde meine Resultate also runden müssen.

[warp-it]

@shark01
Bin gerade auch auf das Phänomen gestoßen. Ist doch kaputt, wenn in Blockly aus 0,002-0,001 der Wert 0,0009999999999763531 entsteht.

[Codierknecht]

@warp-it sagte in Ungewöhnliche Nachkommastellen in der History:

Ist doch kaputt, wenn in Blockly aus 0,002-0,001 der Wert 0,0009999999999763531 entsteht

Nein, ist es nicht. Das Rechnen mit Gleitkommazahlen produziert diese Rundungsfehler.
Das liegt in der Natur der Sache.

https://www.vectorsoft.de/blog/2012/12/rundungsfehler-bei-float-werten

[warp-it]

@codierknecht
Computer sind sooooo doof...

[Thomas Braun]

@warp-it Aber dafür schnell!

[MartinP]

@thomas-braun
Irgendjemand hat mir zumindest für Menschen erklärt, man könnte sie in eine 2 x 2 Tabelle einsortieren ...

{ dumm, klug } x { faul, fleißig }

Dumm und Fleißig - das sind die Schlimmsten.... richten deutlich mehr Schaden pro Zeiteinheit an, als Dumm und Faul ...

Deshalb habe ich nur so einen langsamen Prozessor für ioBroker in Einsatz

[Asgothian]

@warp-it sagte in Ungewöhnliche Nachkommastellen in der History:

@codierknecht
Computer sind sooooo doof...

viel schlimmer. Computer machen genau das was du ihnen sagst - nicht was du von ihnen willst. Und die wenigsten können ihre Aufgabe hinreichend genau spezifizieren dass sie immer gleich und korrekt abgearbeitet wird.

A.

[warp-it]

@codierknecht
Hmmm, der Windows Taschenrechner kann das:

Sogar ich kann das:

[Ro75]

@warp-it Gleitkommazahl, das wurde ja beschrieben.

Ro75.

[MartinP]

@shark01 Das hat etwas mit der internen Darstellung der Gleitkommanzahlen zu tun - ist etwas Hardcore ...

Das Gleitkommaformat ist ein kein platzraubendes Dezimalformat, sondern eine gepackte Binärdarstellungen ...

Die Darstellungs/Rundungsfehler entstehen bei den Umwandlungen aus/zur Dezimaldarstellung ..

https://en.wikipedia.org/wiki/Floating-point_error_mitigation

https://learn.microsoft.com/de-de/office/troubleshoot/excel/floating-point-arithmetic-inaccurate-result

[OliverIO]

@warp-it sagte in Ungewöhnliche Nachkommastellen in der History:

0,002-0,001 der Wert 0,0009999999999763531

aber an javascript selbst liegt das nicht

auch im iobroker als script

console.log(0.002-0.001)

javascript.0	15:13:32.654	info	Start JavaScript script.js.test1 (Javascript/js)
javascript.0	15:13:32.662	info	script.js.test1: 0.001
javascript.0	15:13:32.662	info	script.js.test1: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions

[MartinP]

@oliverio said in Ungewöhnliche Nachkommastellen in der History:

@warp-it sagte in Ungewöhnliche Nachkommastellen in der History:

0,002-0,001 der Wert 0,0009999999999763531

aber an javascript selbst liegt das nicht

auch im iobroker als script

console.log(0.002-0.001)

javascript.0	15:13:32.654	info	Start JavaScript script.js.test1 (Javascript/js)
javascript.0	15:13:32.662	info	script.js.test1: 0.001
javascript.0	15:13:32.662	info	script.js.test1: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions

Schlecht gewähltes Beispiel

Lasse Javascript mal das hier rechnen - genaues Ergebnis wäre 1234567890.0:

log (1234567890.001 + 0.349 - 0.002 - 0.348 + 0.003 + 0.347 - 0.004 - 0.346 + 0.005 + 0.345 - 0.006 - 0.344 + 0.007 + 0.343 - 0.008 - 0.342);

[fastfoot]

@martinp sagte in Ungewöhnliche Nachkommastellen in der History:

Schlecht gewähltes Beispiel

das war das was der TE moniert hatte. Ansonsten muss es nicht sooo kompliziert sein:
log(0.1 + 0.2)
script.js.floats: 0.30000000000000004

[OliverIO]

@fastfoot sagte in Ungewöhnliche Nachkommastellen in der History:

log(0.1 + 0.2)
script.js.floats: 0.30000000000000004

hier ist es tatsächlich so,

aber bei dem TE Beispiel ist es nicht so.
Nachtrag:
ich habe mich mal überwunden das Blockly nachzustellen
und kann das Ergebnis dort nicht nachvollziehen

javascript.0	18:19:06.351	info	Start JavaScript script.js.test2 (Blockly)
javascript.0	18:19:06.378	info	script.js.test2: 0.001
javascript.0	18:19:06.378	info	script.js.test2: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions

von daher alles ok

die Eingangs im log gezeigten Daten können schon sein, aufgrund den zusätzlichen Rechenoperationen.
Wobei ich selbst bei +- Operationen damit nicht gerechnet hätte, sondern eher bei */sqrt. wobei bei Math.sqrt(7)*Math.sqrt(7) = 7.000000000000001 js erstaunlich gut abschneidet