# Bug: Rounding Error on a number that isn't being rounded **URL:** \ **Category:** Product Feedback\ **Created:** [October 1, 2018, 2:52am UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740 "2018-10-01T02:52:42Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![TechPlasma](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/techplasma/32/6644_2.png) [@TechPlasma](https://connect.superhuman.com/u/TechPlasma)\ **Post date:** [October 1, 2018, 2:52am UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/1 "2018-10-01T02:52:42Z")
Whenever I type in 41.76 when on a percentage tab I get this instead. ![image](https://global.discourse-cdn.com/coda1/original/2X/4/4e304ee024c2e3100878b589ecd68ced9cac7039.png) ---
**Author:** ![mallika](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/mallika/32/12981_2.png) [@mallika](https://connect.superhuman.com/u/mallika)\ **Post date:** [October 1, 2018, 4:47pm UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/2 "2018-10-01T16:47:35Z")
Can you use the format dialog to round it to two decimal places and see if that works for you. ![](https://global.discourse-cdn.com/coda1/original/2X/6/61fbd90eefe737f1a6b0d10a80ca7d5284771d87.gif) ---
**Author:** ![TechPlasma](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/techplasma/32/6644_2.png) [@TechPlasma](https://connect.superhuman.com/u/TechPlasma)\ **Post date:** [October 7, 2018, 9:33pm UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/3 "2018-10-07T21:33:03Z")
It does. But that’s more of a band-aid that doesn’t really solve the underlying issue of the number 41.76 being changed by Coda into the number 41.75999999999997. If we cannot trust that the numbers we input into the system are recognized wholly as the numbers we specify. How can we trust that especially large calculations aren’t off by potentially… orders of magnitude? ---
**Author:** ![mallika](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/mallika/32/12981_2.png) [@mallika](https://connect.superhuman.com/u/mallika)\ **Post date:** [October 9, 2018, 4:43pm UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/4 "2018-10-09T16:43:05Z")
I understand. It is a well known javascript floating point issue - [https://support.microsoft.com/en-us/help/78113/floating-point-arithmetic-may-give-inaccurate-results-in-excel](https://support.microsoft.com/en-us/help/78113/floating-point-arithmetic-may-give-inaccurate-results-in-excel) [http://www.saintsatplay.com/blog/2014/08/handling-floating-point-numbers-in-javascript#.W7zY4BNKi3U](http://www.saintsatplay.com/blog/2014/08/handling-floating-point-numbers-in-javascript#.W7zY4BNKi3U) Let me talk to the team and see if there is anything we plan to do. ---
**Author:** ![TechPlasma](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/techplasma/32/6644_2.png) [@TechPlasma](https://connect.superhuman.com/u/TechPlasma)\ **Post date:** [July 8, 2019, 1:56pm UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/5 "2019-07-08T13:56:34Z")
This continues to be an issue. And while it is inherently an issue with IEEE 754. In the case of a professional application intended for business use, it would make sense to have results that people expect, instead of what is returned by the language as a whole. Excel which is the primary program where I see people migrating from does not have this issue. Or at least hides this issue. I would suggest implementing [decimal.js](https://github.com/MikeMcl/decimal.js/) in the background of all the calculations to solve the user-end expectations. ---
**Author:** ![Nick\_Milner](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/nick_milner/32/8249_2.png) [@Nick\_Milner](https://connect.superhuman.com/u/Nick_Milner)\ **Post date:** [July 8, 2019, 2:31pm UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/6 "2019-07-08T14:31:13Z")
FWIW, I’d rather deal with what’s essentially an issue only in theory that can be trivially worked around than add an entire third-party math library into the core stack. I’d limit the number of decimal places anyway. YMMV! ---
**Author:** ![Paul\_Danyliuk](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/paul_danyliuk/32/27228_2.png) [@Paul\_Danyliuk](https://connect.superhuman.com/u/Paul_Danyliuk)\ **Post date:** [November 25, 2019, 4:41pm UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/7 "2019-11-25T16:41:02Z")
I’d add my voice to the “replace IEEE754 with decimal calculations” group. Reason: Coda is already in most other parts designed to behave **as expected by run-of-the-mill user** , not as expected by engineer who knows the underlying intricacies. E.g., all indices start with 1 and not 0, like they all say in jokes about programmers. Hence I’d say there’s no real reason to stick to the JS-native math as @Nick_Milner suggests, but favor the options that offer more precise calculations as perceived by a non-coder. ---
**Author:** ![Jami\_Haavisto](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/jami_haavisto/32/10412_2.png) [@Jami\_Haavisto](https://connect.superhuman.com/u/Jami_Haavisto)\ **Post date:** [November 25, 2019, 5:46pm UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/8 "2019-11-25T17:46:26Z")
I agree. I think Coda should account for the JS error in some form that the user wouldn’t see it. From a regular users’ perspective it’s a bug in Coda (and not in underlying JS), and Coda should have a solution for that. I get frustrated with having to wrap my things that have rounding errors with Round()… ---
**Author:** ![Dominic\_Symons1](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/dominic_symons1/32/15801_2.png) [@Dominic\_Symons1](https://connect.superhuman.com/u/Dominic_Symons1)\ **Post date:** [December 9, 2020, 9:07am UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/9 "2020-12-09T09:07:36Z")
I got the same issue but with super large numbers. I have a list of tracking numbers and they all get rounded! All my tracking numbers end up being identical for all customers. Even if you try and copy and past out later, it pastes the rounded values you have totally lost the actual tracking number info. However, if you double click the field, it shows you the right number. Super weird. I changed the field to a text field to solve the problem. For instance: 943760008683456 943760008683457 943760008683458 Becomes 943760008683000 943760008683000 943760008683000 ---
**Author:** ![Mark\_Sluser](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/mark_sluser/32/7841_2.png) [@Mark\_Sluser](https://connect.superhuman.com/u/Mark_Sluser)\ **Post date:** [June 28, 2021, 8:37am UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/10 "2021-06-28T08:37:33Z")
If coda wants to be taken as a serious replacement for excel this issue needs to be addressed, and hiding the problem doesn’t make it go away. How can we trust the numbers in coda if this issue remains ? Floating point vs decimal numbers in a computer software is fundamental to its operation. I have a doc with tables of financial transactions. Can you assure me that the sums of my account transactions have no errors due to rounding ? ![image](https://global.discourse-cdn.com/coda1/original/3X/e/1/e114351b23eaab58b497950b58687eaa26dcd350.png) ---
**Author:** ![Nurlan\_A](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/nurlan_a/32/21233_2.png) [@Nurlan\_A](https://connect.superhuman.com/u/Nurlan_A)\ **Post date:** [June 28, 2021, 11:31am UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/11 "2021-06-28T11:31:12Z")
I thought that Excel, in comparison with Сoda, is a program proven by many years of use by a large number of users. It turns out that in responsible calculations, additional verification of the results is required for Сoda 🤔 ---
**Author:** ![TechPlasma](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/techplasma/32/6644_2.png) [@TechPlasma](https://connect.superhuman.com/u/TechPlasma)\ **Post date:** [June 30, 2021, 2:48pm UTC](https://connect.superhuman.com/t/bug-rounding-error-on-a-number-that-isnt-being-rounded/2740/12 "2021-06-30T14:48:26Z")
It’s really annoying that this is an issue that continues to persist. One cannot assume that the end-user will have any idea of how math on a computer works, let alone IEEE 754 (Floating Point). And what the ramifications of using it are.