cancel
Showing results for
Did you mean:
Kudo Kingpin

## Power App RoundUp function wrong result (bug)

In my example I have an input control, that updates Contextual Variables based after the OnChange event.

See my formulas on most right of the screen:

RoundUp(66.15,2) should ultimately result in 66.15 because there is nothing to RoundUp. However as you see in my screenshot above, there are numbers (66+68) where it Rounds Up while there is no need for it...

In the exact same decimals used in other "main" numbers (33+34):

it behaves as it should...

I need the construction of two Contextual Variables because of additional business logic. Behavior should be the same though even if I were to use 10 variables (as long as I leave the value intact).

I need to input as text because in some local regions on some (mobile) devices the dot (.) and the comma (,) do not influence the show correctly on the virtual keyboard (but that is another bug-Power Apps Number Input on Mobile - Power Platform Community (microsoft.com)).

Looks like a bug right?

I know the number 6 has some religious meanings, but I would not think Power Apps being superstitious 😁

1 ACCEPTED SOLUTION

Accepted Solutions
Community Support

Hi @Django :
In fact, RoundUp and RouldDown do not have the bug you described. The problem lies in the calculation of floating-point numbers.The point is that floating-point arithmetic is approximate, so it can sometimes give unexpected results with many documented examples.For example:

You might expect the formula 55 / 100 * 100 to return exactly 55 and (55 / 100 * 100) - 55 to return exactly zero. However, the latter formula returns 7.1054 x 10–15, which is very small but not zero. That tiny difference doesn't normally cause a problem, and the app rounds it away when showing the result. However, small differences can compound in subsequent calculations and appear to give the wrong answer.

Number and Currency

So the method I can think of at present is to first convert the floating-point data into an int (reserved effective digits + 1), then perform RoundDown operation, and finally convert it to floating-point data.For example:

``RoundDown((33.16*1000),-1)/1000``

Best Regards,

Bof

6 REPLIES 6
Kudo Kingpin
Super User

It does indeed appear to be an issue with that number.  Oddly enough it is a relatively new idea and notice about it, so I wonder how long this might have been going on, or if perhaps it has been something that came about in the latest release.  Certainly something to remote and keep an eye on.

By the way, there is no need for all the extraneous formulas you have to capture the values into a variable.  Your control already has the value and can be accessed any time you want by referencing it.  In other words, you simply need to reference the Textinput in the places that you want in order to get the value that it has without any variables.   RoundUp(Value(yourTextInput.Text), 2)  will give you the same results without the hassle.

_____________________________________________________________________________________
Digging it? - Click on the Thumbs Up below. Solved your problem? - Click on Accept as Solution below. Others seeking the same answers will be happy you did.
Check out my PowerApps Videos too! And, follow me on Twitter @RandyHayes

Really want to show your appreciation? Buy Me A Cup Of Coffee!
Kudo Kingpin

In my case I need the hassle because of multiple inputs controls on the same screen providing info on the same variables... even related to a gallery with multiple records using the same variables under specific conditions and multiple types of validations... so I won’t bother you with the details but referencing the control directly did not fit all my needs 😅

Community Support

Hi @Django :
In fact, RoundUp and RouldDown do not have the bug you described. The problem lies in the calculation of floating-point numbers.The point is that floating-point arithmetic is approximate, so it can sometimes give unexpected results with many documented examples.For example:

You might expect the formula 55 / 100 * 100 to return exactly 55 and (55 / 100 * 100) - 55 to return exactly zero. However, the latter formula returns 7.1054 x 10–15, which is very small but not zero. That tiny difference doesn't normally cause a problem, and the app rounds it away when showing the result. However, small differences can compound in subsequent calculations and appear to give the wrong answer.

Number and Currency

So the method I can think of at present is to first convert the floating-point data into an int (reserved effective digits + 1), then perform RoundDown operation, and finally convert it to floating-point data.For example:

``RoundDown((33.16*1000),-1)/1000``

Best Regards,

Bof

Kudo Kingpin

So "it works as designed" @v-bofeng-msft?

I think I understand the reason and I even get the workaround:

...but it feels wrong to add and undo a calculation just to get the expected RoundUp/RoundDown result.

Thank you for your help 👍

Community Support

Hi @Django :

Yes it is. I think the Floating-point arithmetic caused the problem.You can find the corresponding explanation in the official documentation:

Thank you for your feedback on this issue and thanks for your solution.

Best Regards,

Bof

Announcements

#### Calling all User Group Leaders!

Don't miss the User Group Leader meetings on January, 24th & 25th, 2022.

#### Power Apps Community Call

Please join us on Wednesday, January 19th, at 8a PDT. Come and learn from our amazing speakers!

#### Community & How To Videos

Check out the new Power Platform Community Connections gallery!

Top Solution Authors
Top Kudoed Authors
Users online (2,430)