News for hackers. Stuff that matters.
Re:C++17 – better than you might think by cm2187 on Thursday December 29, 2016 @07:10AM (#13276868)
In JPY you get there very fast.

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

Re:C++17 – better than you might think by fauigerzigerk on Thursday December 29, 2016 @07:36AM (#13276949)
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.

Re:C++17 – better than you might think by cm2187 on Thursday December 29, 2016 @07:44AM (#13276964)
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.
Re:C++17 – better than you might think by fauigerzigerk on Thursday December 29, 2016 @08:15AM (#13277080)
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.

Re:C++17 – better than you might think by twic on Thursday December 29, 2016 @08:38AM (#13277164)
Last time i did calculations in high finance, we used a (buggy, handrolled) 128-bit fixed-point type for exactly this reason.
Re:C++17 – better than you might think by poikniok on Thursday December 29, 2016 @09:42AM (#13277468)
Thankfully there is __int128 these days natively!
Re:C++17 – better than you might think by twic on Thursday December 29, 2016 @01:30PM (#13279009)
Not in Java, sadly!
Re:C++17 – better than you might think by lmm on Thursday December 29, 2016 @08:45AM (#13277192)
> 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?

Re:C++17 – better than you might think by cm2187 on Thursday December 29, 2016 @09:53AM (#13277535)
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).

Re:C++17 – better than you might think by lmm on Thursday December 29, 2016 @10:25AM (#13277730)
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.