5 ms·
To speed up parallel compilation, use icecc. It's great if you half even two or three computers on your LAN. For high precision currency, use int64_t (perhaps
by jzwinck 10y ago
To speed up parallel compilation, use icecc. It's great if you half even two or three computers on your LAN.
For high precision currency, use int64_t (perhaps in a simple POD class). This, with an 8-digit implied decimal part, is enough to represent the finest price unit in any market today, with a max of 92 billion.
If you are dealing with more than 92 billion of any currency in a single place, don't complain!
- cm2187 10y agoIn JPY you get there very fast. Even in EUR/USD/GBP, a typical large bank balance sheet is over a trillon.
- fauigerzigerk 10y agoTrue. 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.
- cm2187 10y agoNot 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.
- fauigerzigerk 10y agoSure, 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.
- lmm 10y ago> 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?
- cm2187 10y agoI'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).
- lmm 10y agoIf 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.
- pavlov 10y agoAfter 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-offers-new-exchange-rate-1-for-35000000000000000-old-dollars https://www.theguardian.com/world/2015/jun/12/zimbabwe-offer...
- kabdib 10y agoI 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.
- geezerjay 10y agoA 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.
- tcbawo 10y agoA 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.
- user5994461 10y agoDisagree with that. Overflows and rounding errors are not to be taken lightly.
- mingodad 10y agoIf 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 https://github.com/mingodad/sqlite
- deleted 10y ago[deleted]