Hi,
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.

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.

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.

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).

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.

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.

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: