Round with x decimals behaviour

I spent some time figuring out how the Roune with x decimals function works.
I finally was able to understand it and it will save me a lot of trouble in the future.
Here are my thoughts, please someone correct if I am wrong.

I am talking about this function:

I thought this was merely a ROUND function, but as a matter of fact this converts the numbers to a TEXT format.
Usually this is no problem because it can easily be used in another math function and it will be treated as a number.
The problem for me was when Getting this information from Firebase and trying to “Round to 2 decimals” again… then it crashed.

Solution was to keep the “Round to 2 decimals” function only for displays of labels and while uploading to Firebase adding a (variable + 0) function to make sure it is stored as a number in Firebase.

I think the “hint” on the function should be explained better.

1 Like

Nice catch!
Can you make this a feature request in the github?

Can you tell us a little more about what was happening here please @jbonet0073?

When you get data from a Firebase object, that data will be a string - even if your intent is that it be a number - so you will need to convert it to a number first, then perform the rounding.

Was that what was going on here?

1 Like

Hi @domhnallohanlon,
I was not aware all data from firebase should be treated as a string, thanks for the hint.

Here is one potential issue independent from Firebase
In case below Button 1 crashes and Button 2 works fine.

Of course in this case rounding twice is not necessary, but the fact that this function is located in the “Math” section (even blue colored) gives the idea that there will be no harm either.

I like the function, is just the interpretation that is misleading.

Maybe changing the wording to truncates? It doesn’t round it truncates, right

actually it rounds, but with inconsistent rules! (it’s probably a consistent rule but it’s applying to the fractional bit representation of the number, instead of decimal),

3.1449 with 2 decimal places => 3.14
3.1451 with 2 decimal places => 3.15
3.145  with 2 decimal places => 3.15
3.155  with 2 decimal places => 3.15
3.165  with 2 decimal places => 3.17
3.175  with 2 decimal places => 3.17
3.1145 with 3 decimal places => 3.115
3.1155 with 3 decimal places => 3.115
3.1165 with 3 decimal places => 3.116
3.1175 with 3 decimal places => 3.118


Thank you for your research. Indeed, there is a problem with the rounding rules!

You’re right. The loss of accuracy is due to the fact that fractional numbers are stored in binary form, and not in decimal form, as users often understand. For this reason, 0.1 + 0.2 is not equal to 0.3 (if someone didn’t know).

1 Like

I also noticed the following behavior, is it also related to the same issue? this is the reason I needed to round twice in previous example:

Click 1: 10.04
Click 2: 10.44
Click 3: 14.440000000000000001

1 Like

Yes, this is also due to a loss of accuracy. For this reason, you need to work carefully with expressions that use fractional numbers. To avoid errors it is necessary to use rounding.

1 Like

I want to draw attention to the fact that the loss of accuracy occurs only if a fractional number cannot be stored accurately in the binary system. If a fractional number allows to store it precisely, there will be no error, for example, 0.2 + 0.2 is equal to 0.4.

1 Like

Thanks for clarifying.

Can you confirm if this can occur every time when we do algebraic calculations? or only when we use the Round to Decimal functions?

See also:



Integers are fine, it’s only when you get into the domain of real numbers that you run into issues with binary encoding of base 10 numbers. This reminds me of a class on Numerical Methods that I took many years ago. There are lots of good examples online - here’s one that came up with I Googled it just now:


Please see the Domhnall message. He provided a link for a more detailed overview of this issue.

1 Like