PlantSimulation 11.0.12 is behaving interestingly, when comparing two equal numbers.
In the attached model, I have used a table, where column number 4 provides a real number, while column number 5 provides a result basing on a formula.
Both cells do have the same value, but PlantSimulation is assessing them as unequal (just debug the method). To easen it, I have added a debugger screenshot.
I was already wondering, why my models are not working properly at all.
Beside, I wanted to add the model where the bug can be reproduced. Nicely, this forum portal is rejecting that. Obviously Siemens doesn't want to have bugs posted any more.
Then I have a very serious problem with the quality of PlantSimulation, if on one side a given value of 0.000125 and a calculated value of 0.05 * 0.05 * 0.05 = 0.000125 is stored differently (at the twentieth digit after the comma).
You should never compare floating point numbers for an exact match. This problem is not related to Plant Simulation. Floating point numbers are stored in a base 2 representation and not base 10.
This means that 0.1 which looks to you like a number which should be exact has in base 2 endless digits.
But the computer only can store a limited number of places. This makes it difficult to compare numbers which should be the same in base 10 but have a different 'computation history'.
Just tried to upload a model and it works fine. Please retry.
as Ralf stated you shouldn't directly compare real numbers as you did e.g with "\="
This has nothing to do with Plant Simulation but is a known issue to probably all known high level programming languages !
Now there are of course several solutions to your severe problem with Plant Simulation and - in this case- to all known high level languages I know of.
usually you directly compare real /float numbers like this :
abs ( a -b) <= 1e-7, where a, b are your 2 numbers to compare and 1e-7 is an individually predefined accuracy.
In Plant Simulation you can use "==" to compare and set the accuracy through set/- getepsilon.
the default accuracy for epsilon is set to 0.0000001.
Therefore test this code and see
is do local a: real :=0.05*0.05*0.05; local b :real :=0.000125; if a/=b then print "a not equal b",chr(9),chr(9),a-b; else print "a equals b",chr(9),chr(9),a-b; end; if not(a==b) then print "a not equal b",chr(9),chr(9),a-b; else print "a equals b",chr(9),chr(9),a-b; end; end;
I know, it's much more easier to defend an impractical solution than to think about an improvement.
I also know about computer numerics and I am aware about the situation, that the computer systems can not handle an infinite amount of digits (behind the comma) in memory, That's the reason why it is needed to be rounded in case of real variates.
In my example - if you are so kind to look and think first instead of immediately replying - I was using rational numbers. They can be representet with fractions containing of integer values:
0.05 = 1/20
0.05 ^3 = 1*1*1/20*20*20 = 0.000125 -> no need for rounding or any other fancy workaround stuff like in case of using PI or exp.
There are quite an amount of computer programs existing that can handle fractions much more accurate than PlantSimulation does.
Apparently you have found you're own individual "solution" for yourself by
just using rational numbers.
0.05 ^3 -0.000125 =2.71050543121376e-020 ....