Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X
Hello,
I just stumbled upon the weird fact that for Prime1 certain sums are not absolutely correct. For example, Prime1 calculates
1.4 + 0.2 = 1.6
So far, so good.
But if I check if (1.4+0.2) is the same as 1.6, Prime1 tells me it is NOT!
When I create the difference it gives out
1.4 + 0.2 - 1.6 = 2.22*10^-16
which is almost correct but just not correct enough!
In the case of
1.2 + 0.4 = 1.6
Prime1 works correctly.
Please see the attached Prime1-sheet for further examples.
Is this a common error with any calculation software or is this just mathcad?
Is there a way to avoid this error?
Best regards
Sebastian
I think it is "a bug". We have same "bug" in Mathcad 15 when we have not 3-16 digits in rezult 1.4+.2-1.6= but 17 digits (maximum).
BUT why "a bug" not a bug!
The first rule by working with floating point (in Fortran, for example) - do not use the "exact equal" operator and use only the "approximately equal" (see the picture). We can use an "exact equal" operator only by working with strings, boolean, intrgers etc variables.
We must always remember it too by working with "smart" Mathcad .
Hello!
Here what result turns out in Mathcad 15 M010 (so, there is no problem with that):
And in Mathcad Prime 1.0 (It is possible to see what numerical value is accepted for "0"):
Mathcad 15
Above shows the result in Mathcad 15 with default settings (number of decimals: 3).
VladimirN. wrote:
Above shows the result in Mathcad 15 with default settings (number of decimals: 3).
One tour guide at the museum told the visitors that the exhibit has an age of two million and seven years.
All were surprised accuracy of the calculation.
The guide replied that when he went to work at the museum, the main tour guide told him that the exhibit has two million years of age. And since he spent seven years ...
Valery,
"Setting decimal digits to 17 means display all bits in the internal representation. Double floating point precision only supports 15 significant digits, so displaying more than that will show some artifact of the internal representation.
The "17" digit precision is intended for two purposes:
1) when copying the value (as string) it will copy _all_ information internally stored and not round the number.
2) for debugging edge-case situations where round-off bits cause unexpected results (e.g. when rounding or truncating values)."
P.S. This response I received from the technical support PTC, as long ago created a query in the PTC.
Have you formatted the results?
Increased the exponential threshold?
Mike
The difference between Mathcad 15 and earlier versions and Mathcad Prime 1.0, is that Mathcad Prime displays small numbers unlike Mathcad 15.0 which displays small numbers as 0. It's an issue of floating point precision on computers. I am raising this issue with the developers since it came up in another context.
However, if this is evaluated symbolically, it shows the expected result.
Mona
Mathcad Prime 1.0 has double point floating point precision. It's not possible to represent some numbers, due to rounding errors.
If you look at the Formatting tab, you will see that we chose General as the default Result Format, so that small numbers would be displayed, such as Plank's constant:
If you want your small zero's to display as zero, then switch to Decimal in the Result Format, as you see above.
We are discussing ways to increase Mathcad's precision in the future, but that will have an effect on performance.
Mona
Mona,
it will be better if Mathcad Prime returns a more correct units of constants:
I think that here the user can leave a choice (in Mathcad Prime), but rather possibility to control productivity of the computer changing precision of calculations.
Cheers for the explanation Mona,
Mike
Yes, it is evaluated using the symbolic math in Mathcad Prime 2.0 (as shown in the screenshot). There we have the value "0".
See please the picture:
You can change a & b values in attached Mathcad-sheet and see new answer of the a-b operator
PS We have yet discussed this "bug".
I know this is an ancient thread, but it's the first one I found about this.
Anyway, there is an option to calculate approximate equalities by default: