Looked at Prime a time or two at 1. or 2., never used it. But MathCad seems to agree that the first equation is true.

you might try it with parenthesis around the terms individually and combined, then use what works every time.

I'm wondering if there is a weird arithmetical operator precedence rule at play. Perhaps it is parsing the first equation as 12.75 (in) +6 (no units) and stumbling

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?

That will be numerical round-off error.

All Mathcad units are converted to SI prior to evaluation, and a small amount of round-off error can be accumulated in the process. As an example - try evaluating:

12.75 in + 6 * 1.5 in - 21.75 in

This should yield precisely zero mm (or inches), but my copy of Prime 2.0 says it is -1.11E-16 metres.

It's always risky to evaluate a numerical result using exact equality; you really need to set up a test for "close enough to being equal" - where what is "close enough" will depend on your application.

In the evaluation above , the error is about 1/10 the diameter of a proton, which would typically be "close enough" for most practical engineering applications. (It is however MUCH bigger than the Planck Length, so could give erroneous results if quantum effects come into play in your distance measurements! )

http://julianh72.blogspot.com

Ha, I wondered that. But no, that is silly. Apparently not.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?

Mathcad Prime 2.0 has an option to "Approximate Equality". (I'm not sure if this option exists in all versions of Mathcad.)

On the "Calculation" tab, in the "Worksheet Settings" group, click "Calculation Options" then select "Approximate Equality". According to the On-Line Help:

Approximate Equality
Controls the standard used in Boolean comparisons and truncation functions. When this option is not active, two numbers must differ by less than the maximum accuracy of your computer's floating point processor to be considered equal. Numbers from −10^-307 to 10^-307 are considered to be 0. When truncating numbers, all decimal places are used in determining the floor, ceiling, or truncated value of a number.
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, and only the first 12 decimal places are used in truncation.

If the OP enables "Approximate Equality", the original "False" evaluation should now show "True". Note however that this level of approximation (1 : 10^-12) may not always yield the desired "correct" response - this will depend on how you set up your numerical comparisons.

http://julianh72.blogspot.com

Actually, it's still bit odd, since Mathcad 14 shows a zero result, although I think I recall that Mathcad Prime supposedly had additional precision that wasn't displayed.

And that results in the below, even though the conversion to SI units is exact. Mathcad 14 shows zero for the example below

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! https://www.youtube.com/watch?v=BKorP55Aqvg
FAQ731-376: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm

I believe Mathcad 14 used a different "maths engine" to Mathcad Prime, so the exact way that numbers are stored and manipulated could be different.

Don't forget that deep down, Mathcad uses binary numbers for storage and calculation. While Mathcad "knows" that one inch is EXACTLY 25.4 mm (only one decimal place in floating point representation is required for exact precision), the binary repræsentation of 25.4 might be something like 11001.011001100110011.... (with an indefinite number of "binary places" - possibly infinite, to get a precise conversion). Numbers are only stored and manipulated to a finite number of binary digits, so round-off at the last binary digit is to be expected.

Note:
1.1102230246...E-16 happens to be the value of the 53rd binary digit (= 1/2⁵³) past the "binary decimal point" (1/2¹, 1/2², 1/2³, 1/2⁴, ..., 1/2⁵², 1/2⁵³, 1/2⁵⁴, ...), so that is a likely clue as to the nature of the rounding error which is observed.

http://julianh72.blogspot.com

Thank you everyone for the responses! This appears to be a much deeper problem/challenge than I had anticipated. I found that if I write it out and divide out the units, I can make things work! Thank you!

Just remember that dividing out the units is not a guaranteed fix in all cases. Whenever you are adding and subtracting floating-point numbers, there is always a real risk of round-off error in the last few binary digits - and as you have discovered, 1E-11 is not equal to zero!

Many simple decimal fractions can have an indefinite or even infinite number of binary "decimal" places, so round-off error is almost inevitable. (E.g. 0.40 decimal is 0.01100110011... recurring in binary representation.)

Use the "Approximate Equality" function to handle most of these issues for you, but for the most bullet-proof code, create your own test for "close enough" (according to the application).

http://julianh72.blogspot.com

From SMath

Rather than think climate change and the corona virus as science, think of it as the wrath of God. Feel any better?
-Dik

SMath uses its own maths "engine", which presumably uses its own algorithms for handling units, round-off precision, and deciding when a very small number is to be taken as "zero".

Note for example that when you add and subtract several dimensioned terms and end up with a zero result, SMath presents the answer as a unitless "0.00". You can append units of mm (or inches etc), to show the result as "0.00 mm", but you can also append any units you like, and have the result shown as "0.00 kg" for example. SMath evaluates a dimensioned value of "zero mm" (for example) as being unitless 0.00, losing the original dimensions of length in the process, and it will report that 0.00 kg is equal to 0.00 mm.

Mathcad Prime is rather more robust than SMath in this respect - a dimensioned expression which results in a zero value will still show the units as "0.0 mm" (or whatever).

SMath will even evaluate an expression with mixed dimensions if one of the mismatching dimensioned terms cancel out; e.g.:

12.75 in + 6*1.5 in - 21.75 in + 6 kg - 2*2.99 kg = 0.02 kg

Mathcad will flag this expression as having incompatible units.

http://julianh72.blogspot.com

jhardy1... didn'tknow that... I guess if you have 6 apples and 3 oranges and you take 3 apples and 3 oranges away... the correct answer is likely 3 apples...

Rather than think climate change and the corona virus as science, think of it as the wrath of God. Feel any better?
-Dik

Suppose you have 6 apples and 3 oranges, and you take away 6 apples, and then take away 3 oranges - what do you have left?

SMath will tell you that you have nothing (but it won't tell you what it is that you have none of - it could be no apples, or no oranges ... or no elephants, for that matter.)

Mathcad won't even try to work it out - it won't let you add and subtract apples and oranges (or elephants) at the same time.

http://julianh72.blogspot.com

As it should, since dimensional analysis is one way of verifying calculations; playing fast and loose with units is a surefire way of getting wrong answers.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! https://www.youtube.com/watch?v=BKorP55Aqvg
FAQ731-376: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm

Hello,

You could try to round the value on both sides of the equation. We do not have prime but in mathcad15 this works to round down values with units:
Round(12.1234mm,0.01mm)=12.12mm.

Note in Mathcad15 there is a difference between round() and Round().

Regards,
Rob

Quote (SMath will tell you that you have nothing (but it won't tell you what it is that you have none of - it could be no apples, or no oranges ... or no elephants, for that matter.))

As it should be... you have nothing left, whether they be apples, oranges or elephants...

Rather than think climate change and the corona virus as science, think of it as the wrath of God. Feel any better?
-Dik

When you you turn the flow knob to zero, you're getting 0 gpm, not 0 apples, otherwise continuity is violated and dF/dt[0] doesn't exist.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! https://www.youtube.com/watch?v=BKorP55Aqvg
FAQ731-376: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm

Quote (When you you turn the flow knob to zero,)

On the positive side... you likely don't get many elephants, either. Thanks, I never thought of the derivative in that fashion... good memory jogger...

Rather than think climate change and the corona virus as science, think of it as the wrath of God. Feel any better?
-Dik

Zero metres per second is most assuredly NOT equal to zero metres!

If you're doing the maths to rendezvous the SpaceX Crew Dragon capsule with the ISS, you want to calculate something like:

v_Dragon - v_ISS

and try to arrange for this to be close to zero m/s when the separation closes to zero metres.

Things could get pretty ugly if your software decides that zero metres (separation) is the same thing as zero m/s (differential velocity) and allows for a rendezvous with an indeterminate closing velocity.

To put it another way - Mathcad might test for:

Successful docking = Zero separation AND Zero closing velocity

If you're not careful with your test algorithms, SMath might deem a successful docking to occur when:

Successful docking = Zero separation OR Zero closing velocity

Units matter!

http://julianh72.blogspot.com