falsche Vergleiche von Gleitkommazahlen im Script

[jp112sdl]

das die kommunikation integer basiert ist ist klar.

das die kommunikation integer basiert ist ist mir/dir klar.

[Black]

Si... geschrieben vom Handy unter Palmen. Und die automatische Worterkennung und ich werden in diesem Leben keine Freunde mehr

[Matsch]

@Black, ich habe mal deinen Testcode von oben original übernommen und ausprobiert. Tatsächlich spielt dabei die Definition des Wertebereichs der Testvariablen keine Rolle, das Ergebnis ist immer falsch. Warum das bei mir zunächst eine Wirkung hatte? Wer weiß.
Auf jeden Fall hast du gezeigt, dass dies nicht wirklich die Lösung war.

Jetzt habe ich es nochmal mit der Rundung probiert:

Code: Alles auswählen

if (diff.Round(14) != Delta.Variable())
{

und nun probiert, ab wie vielen Stellen nach dem Komma es nicht mehr wirkt.
Bei .Round(14) kommt immer noch das erwartete Ergebnis heraus, ab .Round(15) ist es wieder falsch.
Im Moment sehe ich darin den einzigen "einfachen" workaround.

[Black]

Hi, ich bin im Background mit jens deswegen in Kontakt.

Ich bin auch der Meinung dass dieses nach dem epsilon Vergleich so nicht den dürfte.

Black

[jmaus]

Hi, ich bin im Background mit jens deswegen in Kontakt.

Ich bin auch der Meinung dass dieses nach dem epsilon Vergleich so nicht den dürfte.

Sobald ich dazu komme schaue ich es mir an. Aber auch beim Epsilon-basierten Gleitkommazahlenvergleich gibt es natürlich/vmtl. Corner-Cases. Ich schaue es mir aber zeitnah dann mal an und werde berichten.

[Matsch]

Ich habe noch eine Reihe weitere Versuche gemacht.

Anscheinend ist gar nicht der Vergleich der Übeltäter, sondern die vorausgegangene Subtraktion T_out - T_in !
Wenn ich vor der if-Anweisung das Subtraktionsergebnis runde ( diff = diff.Round(14) ), dann läuft auch der anschließende Vergleich sauber!
Bei der Subtraktion muß also zig Stellen nach dem Komma ein Fehler zustande kommen, der dann zu einer (berechtigten) Differenz führt.
Vielleicht ja nur das letzte Bit?

[jmaus]

Ich habe noch eine Reihe weitere Versuche gemacht.

Anscheinend ist gar nicht der Vergleich der Übeltäter, sondern die vorausgegangene Subtraktion T_out - T_in !
Wenn ich vor der if-Anweisung das Subtraktionsergebnis runde ( diff = diff.Round(14) ), dann läuft auch der anschließende Vergleich sauber!
Bei der Subtraktion muß also zig Stellen nach dem Komma ein Fehler zustande kommen, der dann zu einer (berechtigten) Differenz führt.
Vielleicht ja nur das letzte Bit?

Wie ich schon initial geschrieben hatte gibt es bei Gleitkommaarithmetik eben genau diese Corner-Cases die sich dann mit solchen Symptomen äußern. Auch meine vor längerem eingeführten, epsilon-basierten vergleiche in ReGaHss können das nicht für alle Bereiche abdecken. Deshalb ist es bei solchen Gleitkommaoperationen auch recht üblich statt "delta == threshold" oder "delta != threshold" Vergleichen gewisse Grenzen via "x < a && x > b" abzuprüfen.

Ein paar quellen wo man sich zum Thema Gleitkommazahlendarstellung/verwendung einlesen kann findet man hier:

https://randomascii.wordpress.com/2012/ ... 2-edition/
https://floating-point-gui.de/errors/comparison/

[Matsch]

Nun, dann ist das Thema geklärt und du brauchst dich nicht weiter darum kümmern.

Ich hab wieder was gelernt und hatte anscheinend nur Glück, dass dieser Fehler bisher noch nie auftrat.