After years of hyperinflation, Zimbabwe's currency was entirely discarded last year. The final exchange rate was 35 x 10^15 Zimbabwean dollars for one USD:

"Bank accounts with balances of up to 175 quadrillion Zimbabwean dollars will be paid $5. Those with balances above 175 quadrillion dollars will be paid at an exchange rate of $1 for 35 quadrillion Zimbabwean dollars.

"The highest – and last – banknote to be printed by the bank in 2008 was 100 trillion Zimbabwean dollars. It was not enough to ride a public bus to work for a week."

https://www.theguardian.com/world/2015/jun/12/zimbabwe-offer...

I guess you could move the decimal point a bit and just add zeroes on output for that particular currency. [Not serious, this is a strong argument for int128 for currency... wow]

Gas stations in the US had a similar problem in the 1970s; most pumps didn't go over 99 cents a gallon. Took a few years for things to be retrofitted.

A better idea would be to use a surrogate currency, like a tera- or peta-Zimbabwean dollar, which had a exchange rate of about 1:10^12 or 1:10^15.

I'm sure no one dealing with zimbabwean currency would care for so many significant digits.

A large swath of the finance industry (especially trading) is concerned with optimal speed, not outlier edge cases. They would rather ignore pathological cases like the Zimbabwean currency than sacrifice performance.

There are more commonly-traded currencies, such as the Russian ruble and the old Brazilian cruzeiro, that have had hyperinflation in the recent past.

But you certainly could have a fast path for stable currencies that are very unlikely to hyperinflate (USD, EUR, GBP, JPY).

Disagree with that. Overflows and rounding errors are not to be taken lightly.

Of course overflow and rounding error must be accounted for in your data type. Exchanges have price boundaries, price quanta, or risk boundaries that would guide this decision. My point is that you would not rule out a data type for trading based on an obscure currency like the Zimbabwean dollar.

If you can uses gcc you can use _Decimal64 or _Decimal128, I have a sqlite3 fork that uses it for currency precision calculations. https://github.com/mingodad/sqlite

In JPY you get there very fast.

Even in EUR/USD/GBP, a typical large bank balance sheet is over a trillon.

True. Also, the smallest unit in which prices are quoted is not in all cases sufficient for calculations. A million + 1 rounding errors after the 8th decimal place adds up to an error measured in cents.

In my particular case, 64 bit integers might be sufficient. I thought about it but then decided I wanted to be on the safe side. Maybe not the best decision.

Not sure what sort of assets you are looking at but prices are rarely quoted with a very large number of decimals. Having chunky increments is sort of necessary to match bid and offers on markets.

Sure, but division and multiplication add more decimal places. If you do a lot of calculations and you truncate or round every single intermediate result, rounding errors may add up to unacceptable levels in some cases.

So I wanted perform the caculations with high precision, then round the final result according to what the law requires.

Last time i did calculations in high finance, we used a (buggy, handrolled) 128-bit fixed-point type for exactly this reason.

Thankfully there is __int128 these days natively!

Not in Java, sadly!

> Having chunky increments is sort of necessary to match bid and offers on markets.

How so? If there's a resting offer at 11.58726 and I put in a buy order, limit 11.63492, there's no reason an exchange can't match that and execute either at the midpoint or at 11.58726 +/- maker/taker (whichever the exchange policy is). What's the problem?

I'm not an expert on exchanges but my understanding is that the transaction is executed if the two sides of the order book match or the bid exceeds the ask. If you allow for a very large number of digits in the price, you reduce the probability there will be a match because of a tiny difference between the bid and ask. Won't be a problem on the most liquid securities but more of a problem on less liquid ones.

My understanding is that all prices on exchanges have a fixed number of decimal (and sometimes are even based on less granular base, like 1/8th of a decimal).

If the bid exceeds the ask there will be a trade; if not, the order will rest on the book. That's entirely normal, and a smoothly-functioning exchange should allow granular enough pricing that there would be a clear spread - when the spread is the minimum increment possible (as it usually is in equities markets - the offer is almost always just $.01 above the spread) that is a sign that there are trades that could be executing but aren't (e.g. if the bid is at 5.23 and the offer at 5.24, maybe both parties would be willing to trade at 5.233).

There's an argument that more granular prices make it harder for humans to read the order book but I don't put much faith in it.