
Am 04.04.2017 um 15:46 schrieb Sven Panne:
2017-04-04 7:05 GMT+02:00 Manuel Gómez
mailto:targen@gmail.com>: [...] Check whether regulatory compliance affects your choice of semantics.
This is the most important advice: You'll probably run into legal trouble if you choose e.g. the wrong rounding mode,
I have yet to hear about *any* case where that led to legal issues. Most cases would be laughed out of court anyway - nobody litigates for 0.5 cents. The PR backlash could be much worse.
and for a good reason: If you handle millions of transactions in your system and sneakily always round cents "into your own pocket", you'll be a rich man.
Actually they're insignificant unless you're doing very specialized stuff (microtransactions, long-running debt repayment plans). E.g. for currency conversion, you set a spread which is typically way above any round-off profit you could make. I.e. from a business perspective, it's pointless to try that under most circumstances.
That's the reason behind the tons of rounding modes in e.g. http://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html.
I think these rounding modes have two origins, one of them in the IEEE standard for floating-point numbers, the other is financial calculations. Note that it doesn't matter much which of the modes you use as long as it's reasonable (that's why some countries have "banker's rounding"). You *might* still run into regulations, of course, but I'm pretty sure that if you stick with a specific rounding mode it's essentially okay. Otherwise it would be pretty difficult to run a business with branches in Europe and America, after all.
I have serious doubts that you can handle such things with a floating point representation.
Yeah, floating point is a no-go for monetary values. They can be the right tool when combining percentages, or actualy any factor that is supposed to be multiplied with a monetary value.