Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I'm building an open-source, high-frequency trading system

scarcecapital.com

Post reply on HN
Print view View original

61–70 of 198 posts

Re: Show HN: I'm building an open-source, high-frequency trading system

#61

Post by cakebread »

NateDad wrote: post #40
zygomega wrote: post #26

Earlier quoted context omitted.

I thought so too for a long while, then I tried to do a touch of concurrent code in c++ and had to gouge my eyes out. I'm excited about the speed up haskell brings to development. You can plan things in haskell you can't imagine in other languages.

+1 for doing it in Go. If concurrency is your objective, Go makes it easy... it's also very fast both to program in and to run.

> +1 for doing it in Go

Conspicuously you don't address Haskell at all. Then again, who cares what might actually be best for OP? There's an advocacy bingo card in play!

Re: Show HN: I'm building an open-source, high-frequency trading system

#62

Post by scott_s »

white_devil wrote: post #27
zygomega wrote: post #9

Earlier quoted context omitted.

No, I'm already in the finance industry. There are two main reasons I'm doing this: - I think the finance industry is very closed when it comes to intellectual property development, and an open source approach can be seriously competitive. An open approach may well be the future when it comes to being 'connected' - HFT is an interesting multi-disciplinary problem and the shear breadth of expertise required - modern c…

> an open source approach can be seriously competitive Do you really think any Joe Schmoe off the street could just grab your open source HFT and start making money with it? If not, how does your project benefit anyone? Are you working in the industry, but not in HFT? Maybe this is project is just practise for getting a job in HFT? I imagine that's where programmers get the fattest paychecks in the world. Only a frac…

I don't get your sarcasm at the end of your post. He's stating up front in plain terms what his position is; he's not trying to hide his bias.

Re: Show HN: I'm building an open-source, high-frequency trading system

#63

Post by TheCoelacanth »

white_devil wrote: post #36
cmdkeen wrote: post #20

Earlier quoted context omitted.

It isn't just about liquidity, though it does. But it also reduces the bid/ask spread, i.e. price discovery. The HFT trader may make a tiny profit when it processes a trade from me, but I've benefited because I can buy/sell at a price close to the quoted exchange price, which didn't use to be the case. In terms of liquidity those trades are available to all, they love buying from non-HFT trades because they can make…

It sounds like you work for the financial industry too. > The HFT trader You say it like it's a person making trades. > I've benefited because I can buy/sell at a price close to the quoted exchange price, which didn't use to be the case. What's a "quoted exchange price" if it's not the price you actually pay? > Short term investing is "bad" because you're not investing in the future success of the company you're trad…

> What's a "quoted exchange price" if it's not the price you actually pay?

The actual price you have to pay is based on how much you want to buy and how much other people are willing to sell at what price.

People who want to buy give a "bid" price and people who want to sell give an "ask" price. Whenever there is an ask price that is lower than a bid price, a sale takes place. This results in the lowest ask price always being higher than the highest bid price. The quoted exchange price will be somewhere in between the two prices.

If you want to sell right away, the most you can get is the highest bid price on the books. If you want to buy right away, the cheapest you can get it is the lowest bid price on the books. This means that you have to pay more than the quoted exchange price to buy and receive less than the quoted exchange price to sell.

Re: Show HN: I'm building an open-source, high-frequency trading system

#64

Post by acjohnson55 »

zygomega wrote: post #43
white_devil wrote: post #27

Earlier quoted context omitted.

> an open source approach can be seriously competitive Do you really think any Joe Schmoe off the street could just grab your open source HFT and start making money with it? If not, how does your project benefit anyone? Are you working in the industry, but not in HFT? Maybe this is project is just practise for getting a job in HFT? I imagine that's where programmers get the fattest paychecks in the world. Only a frac…

Good points. To be more precise, I think that an open source approach to system research and design can be hyper-competitive versus closed-door secret-squirrel development run by a committee looking for short-term wins. This project benefits me firstly because I get feedback on my initial scratchings and maybe even collaboration on areas outside my comfort zone. And it could well enable me and others to avoid having…

Others are two lazy? It's my understanding that the average Joe has no access to the hardware and low latency network connections to be able to do this on his own.

Re: Show HN: I'm building an open-source, high-frequency trading system

#65

Post by j_s »

nazka wrote: post #17

I am curious about this project because I love this subject. However, it is impossible to build an open source HFT system especially because it will be open source. The other sharks will know how you trade and they will only need to play against you by sending opposite orders every time. That is what happens when the source code of a big US bank were stolen. So it should be more appropriate to say it will be a fast t…

Just curious... did you actually look at the project before writing all this?

Re: Show HN: I'm building an open-source, high-frequency trading system

#66

Post by zygomega »

boothead wrote: post #59
zygomega wrote: post #46

Earlier quoted context omitted.

Yes, I am aware of that trend and considering a switch. I'm personally more used to R is all, but if I found collaborators I'd jump to where the code base goes. The only other factor is I find R pretty aligned with haskell having a somewhat functional pedigree, so that code translates pretty nicely between a rapid hack at the problem to the more robust approach.

Are you planning to run R in production, or is it purely for research that then gets translated to haskell?

I see the research as production. There's an autonomous system processing the event stream and deciding on trades that's hands free. I see that as a haskell codebase with C speedups for critical stuff, with no R anywhere to be seen.

But then I see a wrapper piece that reports to humans about what's going on within the system. I see R as a great visualization tool for that.

I've had good success so far with using R as a fast column database, solving big data hassles, but there may be better solutions in that space.

Re: Show HN: I'm building an open-source, high-frequency trading system

#68

Post by danielhughes »

zygomega wrote: post #32
nazka wrote: post #17

I am curious about this project because I love this subject. However, it is impossible to build an open source HFT system especially because it will be open source. The other sharks will know how you trade and they will only need to play against you by sending opposite orders every time. That is what happens when the source code of a big US bank were stolen. So it should be more appropriate to say it will be a fast t…

If you need smart algorithms operating autonomously versus motivated enemies your go to must be open source. The security guys proved that a long time ago. You're right in that the HF bit doesn't really fit but 'fast trading' doesn't have the same ring to it.

I don't think your security analogy applies to trading algorithms. Open source is good for security because it aids in the discovery of vulnerabilities. However, good trading algorithms are usually reliant on some form of information asymmetry. If you make a discovery and develop a trading algorithm to exploit it, I would think it would be advantageous to keep it a secret for as long as possible. This is not my field of expertise so please correct me if I'm misunderstanding your analogy.

Edit - I love the project by the way. As others commented already, there's a really strong argument to be made in favor of open sourcing the infrastructure side of this. And that appears to be where most of your effort is focused (e.g. open infrastructure, private trading algorithms).

Re: Show HN: I'm building an open-source, high-frequency trading system

#69

Post by boothead »

boothead wrote: post #59
zygomega wrote: post #46

Earlier quoted context omitted.

Yes, I am aware of that trend and considering a switch. I'm personally more used to R is all, but if I found collaborators I'd jump to where the code base goes. The only other factor is I find R pretty aligned with haskell having a somewhat functional pedigree, so that code translates pretty nicely between a rapid hack at the problem to the more robust approach.

Are you planning to run R in production, or is it purely for research that then gets translated to haskell?

Replying here as I can't add on another reply below

The way we do our monitoring/UI is with zeromq/protocol buffers as an external surface to the trading system (basically a PUB socket) and a very thin bridging and translation layer to WebSockets and JSON in python. That way you get to use d3 or anything else on the front end. We use backbone, knockback and d3 with coffeescript.

Re: Show HN: I'm building an open-source, high-frequency trading system

#70

Post by zygomega »

boothead wrote: post #56
wikiburner wrote: post #48

Earlier quoted context omitted.

Hi boothead, just curious what you do when you run into the inevitable performance issues that can't be ameliorated with libraries like NumPy? Is Cython or PyPy useful, or do you use Python more for prototyping, and rewrite some portions in C?

Python is definitely preferred on the research rather than the production side generally. Some organisations do use it on the infrastructure side too, but these guys are algorithmic traders, and not HFTs so latency isn't that big a deal. WRT to the problem of deploying prototyping/research code, there are the following unsolved problems that I'm aware of: * Going from matrix operations over the whole timeseries (taki…

> Going from matrix operations over the whole timeseries ... to deploying to an environment that streams updates to the timeseries one at a time. I think that this is an area that haskell has the potential to excel at, given it's strong guarantees on structure.

exactly my thought. Algo guys get stuck in matrix land because that's where their tools take them. Whereas this came out in R last week: http://cran.r-project.org/web/packages/stream/index.html

python is a better toolset than R maybe, but the R problem domain seems broader in the last few months anyway.

My interest is in monitoring thousands of algorithms in real time directly within the messaging environment, and before the data hits a database. That type of concurrency is where haskell can muscle up and do the job.

Post reply on HN