Hey All, What do you think of representing prices out past the penny? I'm setting up the data structures for the Ritchie Stock Exchange, and started wondering why we only represent prices down to the penny. If memory serves, this is a sensitive issue.. I recall a story of how profit to be made between the pennies (or eighths, if you go back to the 1900's). In C++, a common type of a decimal number is called a double. This can easily represent a price out to 10 or more decimal places. I personally would not blink an eye if I saw an equity priced at: $32.18905671631346/share The Intel Decimal Floating-Point Math Library is targeted at financial applications, and eliminates rounding error (which can drive you cray-zeeee!) https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library I'm thinking, why not use this library to represent prices as a 128-bit signed double? This would obviously provide much more precise pricing. Hmm... I wonder what the performance trade-off is for larger decimals. Any special reason why pricing is only down to the penny (two decimal places)? There's even lots of room for improvement in Forex, at only five decimal places.
If you're actually trading a real underlying asset, eventually you have to clear the trade. Who keeps the rounding when that happens since that's going to need to eventually be translated to some currency. Are you going to use bitcoin as the currency held? If you round out to any currency, it will be exploited. Furthermore, you need to consider how you're going to handle your own limit order book in an efficient way. Rather than be concerned with the performance impact of copying around and comparing 128bit doubles, consider the performance impact when having to do order matching. What kind of data structure are you going to use to represent the order book? What queuing methods? How are you going to sort it? For illustrative purposes, most limit orders that are not immediately executed (adding liquidity) will be near the money price. In a simple case, you could do a price-level in itself is a FIFO queue implemented in whatever technique you want, but how are you going to sort the different price levels? What I mean is, lets say I have a liquidity adding order at price X. You need to find a price lever match and put my order in that price level's queue. If there isn't a match, then you need to create a new price level for it. When you have a finite number of price levels, this can optimized quite easily. When you have 128 bit numbers, you effectively have infinite price levels. You're going to waste a lot of memory keeping placeholder empty queues, but if you don't you're going to burn a lot of CPU time on searches and inserts. Any reasonably competent programmer should be able to implement an exchange that will work in theory at low volume, but it requires a bit more knowledge of data structures, optimization, and even OS level (ie memory management, paging, and other tricks) to get something that is going to operate at low latency. Now you could very well claim you don't really care about the latency and that's OK, but then you're going to be throwing a massive amount of CPU and memory as well and that ultimately costs money. By thinking through the performance element ahead of time you'll have both lower latency and reduced resource demands. Remember, there's a limit to how much CPU and memory you can throw at a problem depending on your architecture. I'll be honest, I don't think your exchange is going to take off, but I wish you well. It will be quite unfortunate if it does gain traction and then fails due to performance bottlenecks that are not easily addressed once you're live.
Two videos here for you dude. I hope your attempts to trade a market to the 14th decimal place go really well, Mr. Bolton.
fuk that, bring back the eights! i make my money trading small cap and penny stocks and this only works because of the large spreads and increments
Some European stocks are down to 1/10 of a cent.... But I would say that at one point, x-decimal points will not improve computing speed....