Applescript Bug? Subtraktion zweier identischer Zahlen ergibt nicht 0

[n0whereman]

Hallo,

mir ist beim Programmieren eines komplexeren Scripts (zur automatisierten Rechnungserzeugung) ein sehr seltsamer Applescript Bug aufgefallen. Ich habe das ganze mal aus dem Zusammenhang genommen und vereinfacht:

[B]set[/B] a [B]to[/B] 19.9
[B]set[/B] b [B]to[/B] 5.0
[B]set[/B] c [B]to[/B] 14.9

[B]set[/B] d [B]to[/B] a - b
(* d ergibt 14.9, ist also identisch mit c *)

[B]return[/B] d - c
(* Ergebnis: nicht wie erwartet 0, sondern -1.77635683940025E-15 *)

Dieses Ergebnis bekomme ich sowohl auf meinem iMac mit Mac OS X 10.6.8, als auch meinem Macbook Air mit Mac OS X 10.8.4... kommt dieses seltsame Ergebnis auch bei anderen zustande? Im Übrigen funktioniert es mit vielen anderen Zahlenkombinationen tadellos. Man kann das Problem umgehen, indem man nach der Berechnung von d diese Variable in einen String umwandelt:

[B]set[/B] a [B]to[/B] 19.9
[B]set[/B] b [B]to[/B] 5.0
[B]set[/B] c [B]to[/B] 14.9

[B]set[/B] d [B]to[/B] a - b
(* d ergibt 14.9, ist also identisch mit c *)

[B]set[/B] d [B]to[/B] d [B]as[/B] [I]string[/I]

[B]return[/B] d - c

(* Ergebnis: 0 *)

 

[oneOeight]

wird ein rundungsfehler beim umwandeln für die anzeige sein.
so was ähnliches hatten wir mal dem taschenrechner und die wahl der nachkomma stellen...

 

[n0whereman]

es hat definitiv etwas mit den nachkommastellen und vermutlich mit rundung zu tun, ja... aber ein rundungsfehler sollte bei einer so einfachen subtraktionsrechnung nicht zu einem so extrem abweichenden ergebnis führen.
mich würde vor allem interessieren, ob dieser bug bekannt ist...

 

[oneOeight]

in wie fern ist das extrem abweichend?
-1.77635683940025E-15 ist fast null ...

 

[n0whereman]

Ah! Danke, jetzt bin ich auf den wahren Fehler gekommen. Mein ursprüngliches Programm hat innerhalb einer selbstprogrammierten Subroutine zur richtigen Formatierung der Zahlen aus -1.77635683940025E-15 "-1,78" gemacht. Das ist natürlich ein Unterschied.

 

[JeanLuc7]

Vermeide Kommazahlen, denn dann wird intern mit floats statt integers gearbeitet. Der folgende Code liefert das korrekte Ergebnis

[B]set[/B] a [B]to[/B] 199
[B]set[/B] b [B]to[/B] 50
[B]set[/B] c [B]to[/B] 149

[B]set[/B] d [B]to[/B] a - b
(* d ergibt 149, ist also identisch mit c *)

[B]return[/B] d - c
(* Ergebnis:  wie erwartet 0 *)

 

[oneOeight]

Ah! Danke, jetzt bin ich auf den wahren Fehler gekommen. Mein ursprüngliches Programm hat innerhalb einer selbstprogrammierten Subroutine zur richtigen Formatierung der Zahlen aus -1.77635683940025E-15 "-1,78" gemacht. Das ist natürlich ein Unterschied.

da war der rundungsfehler an einer anderen stelle
aber wer denkt da schon an zahlen mit technischer notation...