Simulating a Market in Ruby • Hacker News Board

Re: Simulating a Market in Ruby

#21

Post by munificent » Mon, Dec 02, 2013, 8:56 PM UTC

xedarius wrote: post #11

Limit order books need to need to be very very quick as they usually live in exchanges and process a lot of orders. I've written a few limit order books, I found it difficult to beat this approach. Deal with prices as an int not a float. This important as the price can then form the key of a hash table. Size of the hash table should be the limits of price in your book (including decimal places you support). This seem…

> This important as the price can then form the key of a hash table. Size of the hash table should be the limits of price in your book

Assuming I read you right, I think I would characterize this more as a pigeonhole sort[1] than a hash table.

Which makes sense: the goal here is a sorted collection. And, if you have a known range of values, it's hard to beat a pigeonhole sort for that.

[1] http://en.wikipedia.org/wiki/Pigeonhole_sort

Re: Simulating a Market in Ruby

#22

Post by dclusin » Mon, Dec 02, 2013, 9:10 PM UTC

RyanZAG wrote: post #20

dclusin wrote: post #17

Earlier quoted context omitted.

You're not going to be able to get away from traversing the order book for every match. Another subtle differentiating factor is the time at which the potential matches entered the order book. Obviously priority is always given to price (better price always taken first) but assuming 2 potential orders came into the book for the same price, the one that got there first will be matched. Another thing to think about is…

You can definitely get away with traversals - and they are often required. The simplest method would be to use a sorted list. The head of the list is always the best price, so comparing the best bid against the best offer is linear and can be performed every time the orders are modified. Order insertion is naively O(log n) as the list is sorted, but this can be optimized by keeping a journal of orders and only immedi…

I'm thinking about FX where I work. If the price you get executed at is better than what you wanted your term currency amount changes. Often times what ends up happening is that some someone upstream (e.g. broker) ends up keeping the improvement.

Re: Simulating a Market in Ruby

#23

Post by iampims » Mon, Dec 02, 2013, 11:33 PM UTC

adambratt wrote: post #16

We actually have all of our new developers build a simple working stock exchange when they first start at Benzinga. It really helps those who don't come from a finance background to understand what's actually going on.

Would love to read about the process, mistakes made and overall architecture of building a stock exchange. If you guys are willing to share, that'd be awesome.

Re: Simulating a Market in Ruby

#24

Post by GhotiFish » Tue, Dec 03, 2013, 2:21 AM UTC

iampims wrote: post #23

adambratt wrote: post #16

We actually have all of our new developers build a simple working stock exchange when they first start at Benzinga. It really helps those who don't come from a finance background to understand what's actually going on.

Would love to read about the process, mistakes made and overall architecture of building a stock exchange. If you guys are willing to share, that'd be awesome.

As would I!

Re: Simulating a Market in Ruby

#25

Post by jacques_chester » Tue, Dec 03, 2013, 4:29 AM UTC

CraigJPerry wrote: post #13

First time I've heard of Readme Driven Development, is this a thing? I always lambast myself for continually rewriting the Readme as I go. Part of me sees it as a time drain, or at the very least an admission I've not done sufficient high level strategising upfront. I do keep doing it though!

One of my software engineering professors told how back in the 70s when he was promoted into management, he had his teams write a user manual before starting on coding. He said it brought up all the important fuzzy-requirement problems much earlier in the process, for much lower cost.

Plus, you ensured that there was a manual written. That might not happen otherwise, or it might be done in a rush because of the next project.

It was a different time, but I always found it to be an interesting anecdote.