mmm....I don't think is the REAL data type limit...by doing the same calculation on codesys 3 is ok. Or by trying to adding (50+50.15=100.15 , not 100.1500015..)the result is correct. I think is something related to the fraction and exponent management ...
No one had the same trouble?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2017-09-18
Originally created by: scott_cunningham
You are hitting accuracy errors. Keep in mind that 0.15 is a repeating number in base 2, so depending on internal implementation, you will have an error when you define the value because of truncation. Also, I am pretty sure you will see more accuracy problems with 50-50.15 (negative, fractional number) than with 50 + 50.15. This page (http://ccm.net/contents/62-representati ... d-integers) gives an explanation of how real numbers are stored as a 32 bit number.
50.00 will be: 1.10010000000000000000000 e^(127+5) s=0, m=10010000000000000000000, e=10000100
50.15 will be: 1.10010001001100110011001 e^(127+5) s=0, m=10010001001100110011001, e=10000100
Ultimately, you are subtracting a truncated repeating number, so error will appear sooner.
I created a project with CoDeSys 3.5.6.66 that has an error already with 50.15 (as expected) - see the screen shot. I also used 50.5 instead, and received a "perfect" answer (because 0.5 is 0.1 in base 2 notation). See screen shots.
Are you sure your CoDeSys 3 test was still using 32 bit REALs? With LREAL, you will see -0.15 in the online debug mode, but not in the variable header - you will see truncation error of infinite repeating 0.15 in base 2:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
REAL is not exact, so you can see a small deviation.
the same can be done on a simple calculator, just add 1 and after 1 million times the result will not be exact.
It is indeed to do with the way the mantisse works, as it is not endless resolution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a simple code:
PROGRAM PLC_PRG
VAR
A: REAL:=50.0;
B: REAL:=50.15;
C:REAL;
END_VAR
C:=A-B;
C value is -0.1500015 ? Why?
I'm using 2.3.9.53
Originally created by: scott_cunningham
Accuracy limits of REAL type. If you need higher accuracy, then you need to use LREAL, if it is supported on your platform.
mmm....I don't think is the REAL data type limit...by doing the same calculation on codesys 3 is ok. Or by trying to adding (50+50.15=100.15 , not 100.1500015..)the result is correct. I think is something related to the fraction and exponent management ...
No one had the same trouble?
Originally created by: scott_cunningham
You are hitting accuracy errors. Keep in mind that 0.15 is a repeating number in base 2, so depending on internal implementation, you will have an error when you define the value because of truncation. Also, I am pretty sure you will see more accuracy problems with 50-50.15 (negative, fractional number) than with 50 + 50.15. This page (http://ccm.net/contents/62-representati ... d-integers) gives an explanation of how real numbers are stored as a 32 bit number.
This calculator (https://baseconvert.com/) shows:
Bit deviation starts at bit 20 (23 bits would be absolute max performance, based on 23 bit mantissa)
Now, if we look at your 50-50.15:
50.00 will be: 1.10010000000000000000000 e^(127+5) s=0, m=10010000000000000000000, e=10000100
50.15 will be: 1.10010001001100110011001 e^(127+5) s=0, m=10010001001100110011001, e=10000100
Ultimately, you are subtracting a truncated repeating number, so error will appear sooner.
I created a project with CoDeSys 3.5.6.66 that has an error already with 50.15 (as expected) - see the screen shot. I also used 50.5 instead, and received a "perfect" answer (because 0.5 is 0.1 in base 2 notation). See screen shots.
Are you sure your CoDeSys 3 test was still using 32 bit REALs? With LREAL, you will see -0.15 in the online debug mode, but not in the variable header - you will see truncation error of infinite repeating 0.15 in base 2:
REAL is not exact, so you can see a small deviation.
the same can be done on a simple calculator, just add 1 and after 1 million times the result will not be exact.
It is indeed to do with the way the mantisse works, as it is not endless resolution.