3 ms·
Someone else has already noted this: Don't use the native Javascript Number type for calculations involving currency. There's some great reading available onlin
by ajxs 5y ago
Someone else has already noted this: Don't use the native Javascript Number type for calculations involving currency. There's some great reading available online on this subject.[1][2]
There are various libraries around that can facilitate precise decimal arithmetic in Javascript. A well known one is BigNumber.js (https://mikemcl.github.io/bignumber.js/ https://mikemcl.github.io/bignumber.js/)
A great quote that I found on StackOverflow regarding this issue and wrote down:
"When you are dealing with things that are measured (speed, distance, weight etc.) rounding is OK as the accuracy of the original measurement is probably less than the accuracy of your calculation, and users accept that the final number is still an estimate even if its a good estimate.
When you are dealing with things that are counted (money, people, ICBMs) rounding errors are a disaster. There is always an arithmetically correct answer, and, often the accuracy of this answer is enshrined in regulation, treaties and tax law. Providing a slightly wrong number gets you a free ticket into the Kafkaesque world of auditors, tax collectors and government inspectors; you may never escape with your sanity intact." - James Anderson
[1] https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency https://stackoverflow.com/questions/3730019/why-not-use-doub...
[2] http://blog.plataformatec.com.br/2014/09/floating-point-and-currency/ http://blog.plataformatec.com.br/2014/09/floating-point-and-...
- zakpatterson 5y agoThanks for the write-up. I thought we would be protected because calculations are done using decimal places and then the final return is prepared using rounded integers. But we have heard this a few times, so I think it would be good to make it explicit somewhere that it's done this way, or switch to bignumber. Do you think if all our calculations are done using decimal places, and then numbers are rounded to integer dollars on the final PDFs, that we'll still have errors? Created an issue based on your feedback. Thank you! https://github.com/ustaxes/UsTaxes/issues/457 https://github.com/ustaxes/UsTaxes/issues/457
- evil-olive 5y agothe maximum safe integer in JS is 2^53 - 1. [0] if you can find a way to use only integers within that range, you can do it safely in plain JS. for example, units of integer microdollars (one millionth of a dollar) allows you to deal in amounts up to $9 billion without exceeding the safe integer limit. if you want a larger range than that, you need to make a corresponding reduction in precision (such as using millidollars). or, switch to a full-blown bignum / arbitrary precision library. 0: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- buck4roo 5y agoAt least in the US, tax calculations may round all inputs to the nearest whole dollar. https://www.taxact.com/support/14396/2017/forms-w-2-or-1099-rounding-off-to-whole-dollars https://www.taxact.com/support/14396/2017/forms-w-2-or-1099-...
- caterama 5y ago> If you do round to whole dollars, you must round all amounts. Aww....
- zakpatterson_gh 5y agoCalculate it both ways and display decimals or integers in cases where it makes a $1 tax difference!
- a9h74j 5y agoGood general rule. However, if you are doing some kind of general economic modeling, with estimated parameters all around, not claiming to represent anyone's accounts or ledgers, I suspect an exception applies. "When you are dealing with things that are measured" ... or wild-ass guesses. And I doubt demographers and actuaries are all using integer arithmetic for projecting technically integer-count human-life outcomes. Calculating taxes: Be careful and conventional, as you say.