Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X
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.
you can
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.
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
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.
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:
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:
Workaround could be to strip the units and add them again later:
So a possible (sure not desirable) workaround for your case may be:
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:
In case you need that same way of rounding more often in your sheet, you can create a user-rounding-function like the one shown below , put it somewhere at the top of the sheet (maybe hidden at the right of the page or in a collapsed area and use this instead of "Round".
But i won't guarantee that this function would work OK for all situations.
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 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 😞
Many thanks for your support. I will try your suggestions and feedback.
Hi,
if you have strong nerves, you can consult the problem with PTC Support
@MartinHanak wrote:
Hi,
if you have strong nerves, you can consult the problem with PTC Support
Toi, toi, to! Good luck and knock on wood! 🙂
I'm wondering if the rounding is being driven by using IEEE 754 rules for rounding half to even.
From Wikipedia:
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.
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.