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:
