---

bug.jpg

Hi everyone,

I've been working with plant simulation for 3 years now, but during all this time I've never seen such a thing

(see attachement)

I have 2 values (actualcont and bookthis) which when soustracted bring an round up error which I really can not explain. See the example:

actualcont = 0.23568
bookthis = 0.22632

----

actualcont - bookthis = 0.009360000000000035 (instead of 0.00936)
actualcont + bookthis = 0.462
actualcont - bookthis + 0 = 0.009360000000000035
actualcont - bookthis + 1 = 1.00936
actualcont*1000 - bookthis*1000 = 9.360000000000035

--

Can anyone explain me this effect ? The raison of this round up error ? Is their a way to fixe this without using round(actualcont - bookthis,5) ?

Which difference causes my model to crash after a while that's how I found it.

Thank in advance for your explainations and solutions

(Answer in German or English are fine for me)

------------------
Thomas Carlin
Process Engineer
BASF SE

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Dass Rundungsfehler auftreten können, sollte doch eigentlich bekannt sein. Intern haben 64-Bit-Gleitkommazahlen ca. 16 Dezimalstellen. Beim Anzeigen rundet Plant Simulation Zahlen meist auf 15 Stellen:

Code:

---

print 1/3;        -- 0.333333333333333
print 1/3 - 0.3;  -- 0.333333333333333
print 1/3 - 0.33;  -- 0.033333333333333
print 1/3 - 0.333; -- 0.000333333333333297

---

Intern werden die Gleikommazahlen im Binärsystem gespeichert. Es gibt Zahlen, die im Dezimalsystem exakt darstellbar sind, aber im Binärsystem unendlich viele Nachkommastellen benötigen würden, z. B. die Zahl 0,7. Daher ergibt 0.7-0.5-0.2 nicht Null. Es handelt sich hierbei nicht um einen Rundungsfehler im klassischen Sinn, da der Fehler hier nicht bei der Subtraktion auftritt. Vielmehr wird die Zahl 0.7 bei der Wandlung in eine Gleitkommazahl auf eine Binärzahl gerundet, die nicht mehr der dezimalen 0.7 entspricht.
Prinzipiell haben alle Computerprogramme diese Probleme mit Gleitkommazahlen. Es gibt mehrere Möglichkeiten, diese Probleme zu minimieren, z. B. indem man mit BCD-Zahlen oder mit Brüchen rechnet. Dies ist aber langsam und löst die Probleme trotzdem nicht vollständig. Auch der Windows-Calculator hat irgendwann Rundungsprobleme, z. B. bei 2 ^ 0.5 ^ 2 - 2.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Thank you for your fast answer,

I am still suprised that actualcont+bookthis returns a exact answer whereas actualcont-bookthis returns an approximated answer. I would expect the same approximation in both cases ...

If I follow you, this is normal and is unavoidable. I guess I will have to use for example round( the mathematique operation , 10) everywhere to avoid such a problem or to be very carefull to use >==, <== and == everwhere instead of >, <, = .

Anyways, thanks for taking the time to answer me.

Thomas Carlin

------------------
Thomas Carlin
Process Engineer
BASF SE

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

I would advise against rounding. It sometimes makes a big problem out of a small one. But I recommend to use == when comparing floating point values.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP