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?
Let me talk to the team and see if there is anything we plan to do.
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!