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.
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.
If someone sells you 12345.55 EUR vs USD at a rate of 1.12345, how many EUR do you think you end up with? Do you think all market participants even agree? What if the rate is 1.123456?
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?
Of course market participants agree?
Exchanges have calculation rules for every type of mark and payment and will always specify rounding.
You store the sums on either end, the currencies, the exchange rate and the final sum? No one has .0000145 cents in their account. Rounding occurs in the real world.
> You store the sums on either end, the currencies, the exchange rate and the final sum?
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
It is fine as long as you don’t cross any edge cases (crypto, or more recently stuff like AI token pricing) and don’t forget to account for third party quirks (e.g. Stripe’s zero-decimal currencies: https://docs.stripe.com/currencies#zero-decimal).
JPY not having any minor units is arguably not a “third party quirk” but just how the currency works. The same goes for various three decimal digit currencies.
If you’re only trading in USD and other two-decimal currencies it can work fine, yes. For anything else, it’s much worse as also detailed in TFA.
You provide different handling strategies for different currencies. You also sort currency data alongside your amount. There is nothing complicated or edge-case here.
This works for USD, JPY or $MEMECOIN and it scales very well.
Agree with this, working from HFT to payments to account management in the past.
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.
Big decimals are widely available and don’t require any expertise but avoid many of the footguns of implied decimal integers.
BigDecimal should be used by almost everyone except for HFT since they're really slow.
Imagine advising someone who explicitly said they work in HFT to use big decimals.