Having done HFT / low-latency in C++ with a browser based (read: JavaScript) management front-end: Go ahead and use integer cents everyone. It’s practically an industry standard and it works just fine. Anything else is a worse compromise.
For added fun, you can introduce division. Some systems will allow you to sell 12345.55 USD to buy EUR at a rate of 1.12345.
The article’s “no lost data” tenet is not really viable when this sort of division is involved. Are you going to track your account balance is a rational number with an absolutely immense denominator forever?
There is a remarkable amount of disagreement as to whether one should do one’s back office work based on the price or based on the quantity of the counter currency.
> No one has .0000145 cents in their account. Rounding occurs in the real world.
Indeed. But you either need to convince all parties to agree to round the same way or you need to accept small errors
So, yes, everyone has to understand how all their partners are doing rounding and summing.
I would, however, by quite surprised if my personal bank account did this.
When you owe the bank money, they round up.
Exchanges have calculation rules for every type of mark and payment and will always specify rounding.
1. If someone sells me 12345.55 EUR, I hope to end up with 12345.55 EUR.
2. That's the point though. They will sell you a certain amount of EUR at a certain dollar price. This, in turn, implies a rate (which might well have more than 5 digits behind the decimal). This is ideally close to the quoted rate, sure. But what counts is the actual EUR amount and the actual USD amount, not what rate was quoted or with how many digits.
You can have the blockchain team be an expert in converting integer cents, or the forex team be an expert in sub-cent conversions. You don't want to require _every team_ to have expertise in float math, by default.
This works for USD, JPY or $MEMECOIN and it scales very well.