Whenever I type in 41.76 when on a percentage tab I get this instead.
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?
1 Like
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
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.
1 Like
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 in the background of all the calculations to solve the user-end expectations.
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!
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.
1 Like
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()…
1 Like
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
1 Like
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 ?
2 Likes
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 
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.