Hi!
I surprisingly found that Mathcad calculates this simple expression wrong:
Both results must be the same. The second result is the correct one.
It gets even worse in this case:
It seems that Mathcad accumulates floating point errors in sums, which can be easily avoided (or greatly reduced) by applying a proper summation algorithm. It costs nothing to implement, so why not do it?
ACCEPTED SOLUTION
Accepted Solutions
So the option you have are
a) Talk PTC into changing the built-in algorithms (don't hold your breath)
b) Use the symbolic engine for evaluation
c) Implement Kahan as a user defined function. As you see below, it does its job
I was also curious what it would mean to calculation time and used a crude timer function.
It looks like Kahan increases execution time by about 25%. But I guess it could be significantly speeded up by programming in Visual Studio and turning it into a Prime Custom function DLL.
I guess that what you experience is the typical limitation of numbers stored in IEEE format and its typical 14-15 valid significant digits. Additionally the subsequent conversion of all units to standard meter makes it even worse. You probably know that a number like 0.1 is a periodic number in the binary system and so has to be cut off somewhere.
For more precise results you may use the symbolic evaluation. You may have to turn on the calculation option to use constants and units in symbolics.
Even if you turn on this option, you still will have to tell the symbolics that 1 cm equals 0.01 m, etc. Either by redefining the units in the worksheet or by using the "substitute" modifier. Unfortunately the symbolics still does not know much about units.
BTW, if you define a new unit like dm, you should make it a "real" unit by labelling it as a unit and not, as you did, as a variable.
You may also like this well known example which shows, that the commutative law for addition does not apply to "computer numbers".
Compare the last two digits of the result:
And if you have a couple of cups of coffee ready, you may try to symbolically evaluate both expressions. It will take a while and the result most likely is a fraction of two huge integers which you can turn into a floating point number using the "float" modifier.
OK, Thank you, Werner!
I am still evaluating Mathcad, but I can try as you suggest. Probably, they have too many clients and will not want another one. 😉 But for the money they require, I would expect a software to the highest standards.
What I mean are methods like pairwise (cascading) summation, or the Kahan summation algorithm.
For the example with the units, I get zero error when I implement my own routine. So, both results are the same with double precision floating point and no symbolics. And it also performs much faster.
But it seems that Mathcad simply adds consequently each member to the sum (sum += x_i, i = 1..n) and in this way, accumulates the rounding error. Consequent summation is not good because, as the sum grows, you start adding many small numbers to a much larger one and lose significant digits each time. 😞
So the option you have are
a) Talk PTC into changing the built-in algorithms (don't hold your breath)
b) Use the symbolic engine for evaluation
c) Implement Kahan as a user defined function. As you see below, it does its job
I was also curious what it would mean to calculation time and used a crude timer function.
It looks like Kahan increases execution time by about 25%. But I guess it could be significantly speeded up by programming in Visual Studio and turning it into a Prime Custom function DLL.
