Hacker News new | past | comments | ask | show | jobs | submit login

> There are pros and cons but as long as you do rounding and comparisons correctly it works perfectly fine.

This is exactly the issue with using floats where an arbitrary precision decimal with proper rounding is really needed. Easily solved with a good library and if your languages supports it, type, but it's really easy for a dev in a hurry to not use the library and roll some a=b+b*c_rate code that forces some type conversion. The rounding rules often are tied to contracts, and a subtle bug that's off a few mills here (total problem created $2.33) and there can lead to audits (total cost of audit $14,800) that cost a lot.




I'm tired of having to drag in another dependency and lose operators if I'm doing money math. I can create an experience in C++ that's almost rational, with operator overloading, but most other languages were designed well after we knew that doubles are not sufficient. And there's more than just arbitrary precision. For example,, some currencies use three decimal or no decimal places. Two just happens to be convenient for the Euro and Dollar. In addition, sometimes you carry prices to 3 or 4 places. But you still want banker's rounding. And I shouldn't be able to add Turkish Lira to US dollars, any more than the language allows adding floats and integers, without conversion. Then there's locale correct display for currencies (e.g. $ vs USD and before or after the money amount).


you can also easily hurry up subtly wrong money math with ints. (overflows, wrong rounding method, etc). So you should not in any case use the default math operators


At least with ints you can capture those issues with intent and handle them properly (as the better libraries that handle money tend to do).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: