# Average formula gives wrong result

**URL:** <https://connect.superhuman.com/t/average-formula-gives-wrong-result/24166>\
**Category:** Bugs\
**Created:** [June 22, 2021, 8:20am UTC](https://connect.superhuman.com/t/average-formula-gives-wrong-result/24166 "2021-06-22T08:20:58Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Federico.Stefanato](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/federico.stefanato/32/21115_2.png) [@Federico.Stefanato](https://connect.superhuman.com/u/Federico.Stefanato)\
**Post date:** [June 22, 2021, 3:01pm UTC](https://connect.superhuman.com/t/average-formula-gives-wrong-result/24166/3 "2021-06-22T15:01:24Z")

</div>

Dear @Nurlan_A,

As @Jean_Pierre_Traets suggests, you can either rounding your formula or limit the decimals in the column settings.

Please, find the comprehensive answer here:

> [@Problem with Uploading Data (Extra Decimal Points for Percentages)](https://connect.superhuman.com/t/problem-with-uploading-data-extra-decimal-points-for-percentages/13088/2):
>
> Known issue, Coda is using IEEE 754 for floating point math. This is pretty much the standard for all programming platforms and is native for processors. The problem is that only decimal parts that are 1/2, 1/4, 1/8, 1/16 etc (half of the previous one) or their sums (e.g. 0.75 as it’s 1/2 + 1/4) can be accurately represented in this encoding, while for 0.8 there’s no way to accurately store it as a sum of these fractions, hence these …000000002%. The solution would be implementing some sort of …

And in another thread:

> [@Bug: Rounding Error on a number that isn't being rounded](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740):
>
> Whenever I type in 41.76 when on a percentage tab I get this instead.

---

_[View the full topic](https://connect.superhuman.com/t/average-formula-gives-wrong-result/24166)._
