ACCEPTED SOLUTION
Accepted Solutions
While you may think that both variables are of exact same value, that's not true.
You can see that there is a difference of slightly more than 10^-15 in and t.provided is actually smaller than t.required for that tiny amount. Hence you get "Not OK" as the answer.
These round-off errors or numerical inaccuracies are normal and to be expected. Tiny round-off errors when doing calculations or unit conversions (Prime stores internally in SI unit meter) are the cause.
Its a golden rule never to check float values for equality but rather for approximate equality.
So don't use "if a=b ..." but rather "if |a-b| < 10^-10 ...". You decide for the level of accuracy and it does not matter if you use < or <=.
In your case you could cope with the problem by doing it that way:
10^-14 in might be too small for other values. You have to decide if an accuracy of 10^-6 in or 10^-8 in wouldn't be al you need.
To turn it into a function you could make the accuracy level a third function argument:
Or you may use
Here the third function argument represents the number of decimals needed as accuracy.
The division by the unit in does not affect the variables. Its just needed for the usage of "round".
You may also use the "Round" function (note the capital "R") to again provide the tolerance in inches as third argument:
A float value usually is said to be accurate up to 15 to 16 decimals. Given that 10^-15 meter is roughly 4*10^-14 inches, I would not expect a higher precision than 10^-14 inches. And round-off errors can accumulate if the value is derived by a series of calculations.
So demanding a precision of 10^-10 inches might be considered realistic but nonetheless ambitious. Normally I guess a much larger precision might suffice.
There's nothing wrong with Mathcad, you're experiencing small differences in actual numerical results and mathematical formatting:
The comparison of the two values using inches does not alter the value input of trequired or tprovided so the unit you use to define them is still intact.
They are just compared in the test in inches to three decimal places.
What a weird bug for Mathcad to have :
Dividing by the specific unit in question works as long as you select the correct unit and number of digits each time (tedious). Some engineering values may have a tighter tolerance, but most construction materials are sold with 2 or 3 digits (...I know, the material is what's sold, but the accompanying data sheets usually only report 2 or 3 significant digits.)
But if you simply divide the two variable, the question of compatible units goes away and the same formula can be repeated for all the checks throughout the document. Then, rounding the result to three digits is more than enough for most engineering applications (depending on your specific industry).
Here are some simplifications. I prefer the in-line formula because normal reading style is to read across, then down. So for the 'program style', the last line always says "Not OK" so it becomes distracting for the reviewer—keep is simple s-----!
Even better if you define a "generic" check function so that all the reviewer only sees is the result of the check, not the same distracting program every time:
I won't call it a bug as its the normal behaviour to be expected when working with IEEE float numbers.
But I agree that it can be an annoyance.
While displaying the converted 6 inches up to the max 15 decimals in mm does not show anything unusual, it can be seen by taking the difference that the converted 6 inches actually are slightly smaller than 152.5 mm.
You may get the expected zero by setting the zero to a lower value than the standard 15, but this does only affect the display of results and not the precision used in internal comparisons:
BTW, in real Mathcad when we demand to show 17 decimals we see
You may also define your own comparison operators.
Its doubtful if they would be helpful, though, because they are cumbersome to use (copy & paste) and because on contrary to real Mathcad we are not offered the usage of a function in two arguments in inline notation its not really good looking.
An option might be something like
Using the quotient and that way getting automatically rid of the units is a good idea.
While you may think that both variables are of exact same value, that's not true.
You can see that there is a difference of slightly more than 10^-15 in and t.provided is actually smaller than t.required for that tiny amount. Hence you get "Not OK" as the answer.
These round-off errors or numerical inaccuracies are normal and to be expected. Tiny round-off errors when doing calculations or unit conversions (Prime stores internally in SI unit meter) are the cause.
Its a golden rule never to check float values for equality but rather for approximate equality.
So don't use "if a=b ..." but rather "if |a-b| < 10^-10 ...". You decide for the level of accuracy and it does not matter if you use < or <=.
In your case you could cope with the problem by doing it that way:
10^-14 in might be too small for other values. You have to decide if an accuracy of 10^-6 in or 10^-8 in wouldn't be al you need.
To turn it into a function you could make the accuracy level a third function argument:
Or you may use
Here the third function argument represents the number of decimals needed as accuracy.
The division by the unit in does not affect the variables. Its just needed for the usage of "round".
You may also use the "Round" function (note the capital "R") to again provide the tolerance in inches as third argument:
A float value usually is said to be accurate up to 15 to 16 decimals. Given that 10^-15 meter is roughly 4*10^-14 inches, I would not expect a higher precision than 10^-14 inches. And round-off errors can accumulate if the value is derived by a series of calculations.
So demanding a precision of 10^-10 inches might be considered realistic but nonetheless ambitious. Normally I guess a much larger precision might suffice.
