Community Tip - You can change your system assigned username to something more personal in your community settings. X
Hello Everyone,
I hope everyone is going to have a great week ahead. I am having a problem with a if else statement. Although my summation is matching from both sides but it is evaluating as "False" in output. It would be very nice if you can help me out with it.
Thanks
Faisal
Solved! Go to Solution.
If all units are removed, it also works
I suspect the issue arises because, behind the scenes, Mathcad is working in meters. So, working with feet engages a additional conversion calculation and that throws it's accuracy off.
You're running afoul of numeric precision; the summation is not exact, so the difference is trivially small but not zero. Reformulate your test:
So Mathcad is not good with English Units
No, Mathcad is fine with units.
Like any other machine addition process, there is a small but finite error in each mathematical calculation. You're sheet is doing twelve additions, so the error is multiplied by 12. Then you asked if one number was exactly equal to another, and your computer (not Mathcad) looked at the two numbers and decided they wer not identical.
One of my early calculators would error if I took the sine (of the (sine of( the sine (of 1 degree))), then took the arcsine( of that number) three times; the last operation asked for the arcsine of a number larger than 1. It was trapped by the error that crept into the process.
Research "numerical accuracy," it's been a dilemma for computer programmers since there were computers.
I have compiled a similar problem used in SI units....and it has to do almost 29 summations....I used that with Mathcad and it didn't have the problem that was in English units....
By George you're right:
But I don't know why.
I suspect because internally Mathcad runs fully in SI units. This means that for English units mathcad has to do more mathematical operations, so introducing more of those small deviations. But (unless you can keep your numbers in the integer range, which is the case for the calcuation in m) you should always take care when checking equality between two numbers.
Retry the same test with mm instead of m. My guess is that it'll go wrong at some point too.
Luc
If all units are removed, it also works
I suspect the issue arises because, behind the scenes, Mathcad is working in meters. So, working with feet engages a additional conversion calculation and that throws it's accuracy off.
And it looks like it solves as desired if you turn on the "Approximate Equality" option on the Calculation tab.
I tried with the "Approximate Equality" but it wasn't working either
And I tried with this and it worked......I have seen lately that Math cad has released Prime 4....I hope it will be revolutionary
This issue is exactly why Mathcad has the "Approximate Equality" option. The same "error" can even happen using fractions:
The above returns true (1) when the "Approximate Equality" option is turned on.
you can try with English units and it won't work....I have seen the CTOL and TOL and my tolerance limit was beyond what Mathcad has offered
Seems to work fine for me (with "Approx Equality" turned on):
It doesn't work when you compare between two long ( i.e 15) summations in ENglish units
Can you post an example? Anything I try seems to work fine with "Approx Equality" turned on.
Seems to work just fine for me:
Compare by Subtracting LDesign with Sum d and see if it holds true
Interesting:
Here's a portion of what Help says regarding Approx Equality:
When this option is active, the absolute value of the difference between two numbers divided by their average must be < 10^-12 for them to be considered equal.
Mathcad is taking the difference between each side of the equality sign, and dividing by the average of the two values. Since the average is so small (nearly zero), the result is larger than 10^-12.
Moral of the story: "Approx Equality" isn't good at comparing values to zero.
I hope this will not be a issue in Prime 4
I just got 4.0 (free version for 30 days). Unfortunately, it gives the same results.