Skip to main content
D
DC_110719771-Visitor
1-Visitor
May 10, 2024
Question

Rounding Issue - MathCAD Prime 9

  • May 10, 2024
  • 4 replies
  • 2823 views

I am hoping you can help.

 

As you can see below, I would like B17 to be 32.95, as if B15 is 0.005 and above, it should round up. And if it is 0.004 and below, it should round down.

DC_11071977_0-1715334652764.png

 

you can 

4 replies

W
Werner_E25-Diamond I
25-Diamond I
May 10, 2024

Its hard to impossible to debug just a picture!

 

Possible explanation: The value of B15 might be something like 32.94496321... mm and because you set Prime to display four decimals, the correct display would be 32.9450 mm. The correct value rounded to the nearest hundredth mm would be 32.94 mm.

 

For further help you would have to attach your worksheet, not just a picture.

D
DC_110719771-VisitorAuthor
1-Visitor
May 10, 2024

Thank you for the reply, the sheet is part of many sheets that form our design intent, so unfortunately cannot share the sheet.

 

By changing the d.p.  It still is incorrect, as round up to 2 dp should be 32.95

 

DC_11071977_0-1715335983293.png

 

W
Werner_E25-Diamond I
25-Diamond I
May 10, 2024

B15 still could be 32.949999999999999999999999999999123 because of round-off errors of prior calculations or because of length unit conversions.

Can't say more without seeing the data.

 

You can try to isolate the problem somehow and create a new demo worksheet just showing the error and not the sensible data.

 

What do you get if you evaluate 32.945 mm - B15 = ?

 

EDIT: OK, tried it myself and could duplicate the error.

Werner_E_0-1715336979214.png

As you can see, B15 is slightly smaller than 32.945 mm (about -7*10^-15 mm).

Reason seems to be round-off errors due to Primes internal unit conversions, because all is OK if I remove the units or if I use m instead of mm.

Actual problem seem to be the adding of the 5 um as you can see here:

Werner_E_1-1715337538077.png

You may report the problem to PTC support but I guess that numerical round-offs can hardly be fixed without opening new bugs.

Seems that you have to find a workaround which fits for your application. Maybe some kind of "double rounding".

EDIT 2: Rounding twice (B15 to 12 decimals and then what you did for B17) does not work because we run into similar problem when we use the rounding function:

Werner_E_1-1715338388062.png

Workaround could be to strip the units and add them again later:

Werner_E_2-1715338425690.png

So a possible (sure not desirable) workaround for your case may be:

Werner_E_3-1715338579266.png

If you decide to go into the troubles of contacting PTC support, let us know the outcome, please.

 

 

 

Here some simpler examples of the same problem:

Werner_E_0-1715337963164.png

 

 

M
MartinHanak24-Ruby III
24-Ruby III
May 10, 2024

Hi,

it seems to me that the problem is related to unit conversion.

SI unit system uses m as default and you are converting m to mm.

MartinHanak_0-1715338788161.png

 

W
Werner_E25-Diamond I
25-Diamond I
May 10, 2024
@MartinHanak wrote:

Hi,

it seems to me that the problem is related to unit conversion.

 

Correct!

Actually, as shown above, that kind of error occurs twice in the given example.
The first time, when the 0.005 mm are added and then again when the "Round" function is used with 0.01mm as second argument.

 

Its hard to deal with that kind of error and the solution depends on the specific application. My 'solution' above sure is not a general solution for all situations 😞

D
DC_110719771-VisitorAuthor
1-Visitor
May 10, 2024

Many thanks for your support. I will try your suggestions and feedback.

B
23-Emerald III
BenLoosli23-Emerald III
23-Emerald III
May 10, 2024

I'm wondering if the rounding is being driven by using IEEE 754 rules for rounding half to even.

From Wikipedia:

Rounding half to even

One may also round half to even, a tie-breaking rule without positive/negative bias and without bias toward/away from zero. By this convention, if the fractional part of x is 0.5, then y is the even integer nearest to x. Thus, for example, 23.5 becomes 24, as does 24.5; however, −23.5 becomes −24, as does −24.5. This function minimizes the expected error when summing over rounded figures, even when the inputs are mostly positive or mostly negative, provided they are neither mostly even nor mostly odd.

This variant of the round-to-nearest method is also called convergent rounding, statistician's rounding, Dutch rounding, Gaussian rounding, odd–even rounding, or bankers' rounding.

This is the default rounding mode used in IEEE 754 operations for results in binary floating-point formats.

V
vnamboodheriCommunity Manager
Community Moderator
May 16, 2024

Hello @DC_11071977,

 

It looks like you have some responses from some community members. If any of these replies helped you solve your question please mark the appropriate reply as the Accepted Solution. 

Of course, if you have more to share on your issue, please let the Community know so other community members can continue to help you.

Thanks,
Community Moderation Team.

Terms & ConditionsCookie settingsAccessibility statement