Live data from Hacker News

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

scarcecapital.com

81–90 of 198 posts

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

#81
I would be much more interested in an open source solution to fight against HFT, or at least make it more difficult.

I see the financial world as a necessary evil, and I think some of its parts have benefits for the rest of the world. HTF is not one of those parts; I see it as a pure burden.

You could have made an open source Patent Trolling system and I would feel the same.

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

#83

Earlier quoted context omitted.

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.

Thatsvery similar to what I/we use to build our realtime network monitoring tools, swapping out python for PHP (regrettably). It's validating to see other shops in different industries zeroing in on the similar stacks.

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

#84

Earlier quoted context omitted.

We have some plans on the drawing board for market maker simulators that could do with some fast matching so I'll keep an ear open for that ping.

What sort of performance baselines would you require?

I have no idea yet. I see you're geeking out in go and there's been a lot of advocacy coming through to look at go as an alternative.

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

#85

1. Timestamps in your seed data might benefit from nanoseconds if you really talking about "high" frequency. 2. I agree with you comment that it is easier to think about concurrency in Haskell than in something like C++, however you can't really compete with C/C++ in Haskell. Not even with cgo (Go packages that call C code), not with OCaml or any other higher level beasts that promise the speed. Fortran would be the…

I wish I could get down to nano units. iqfeed (a good value feed) just got millisecs in so will settle for that. I'm preparing some speed tests between C++ and haskell on an identical block of processing so stay tuned! You might be surprised - haskell is way ahead of clojure on compiler smarts. The split you suggest is exactly what I think is wrong with the way things get done right now. I'd like to integrate the qua…

Keep in mind that if you're not an experienced C/C++ coder, you're going to be (largely) benchmarking your relative ability in either language rather than the intrinsic speed of each language.

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

#86

1. Timestamps in your seed data might benefit from nanoseconds if you really talking about "high" frequency. 2. I agree with you comment that it is easier to think about concurrency in Haskell than in something like C++, however you can't really compete with C/C++ in Haskell. Not even with cgo (Go packages that call C code), not with OCaml or any other higher level beasts that promise the speed. Fortran would be the…

I wish I could get down to nano units. iqfeed (a good value feed) just got millisecs in so will settle for that. I'm preparing some speed tests between C++ and haskell on an identical block of processing so stay tuned! You might be surprised - haskell is way ahead of clojure on compiler smarts. The split you suggest is exactly what I think is wrong with the way things get done right now. I'd like to integrate the qua…

[deleted]

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

#87

Have you considered python for the research/algo side of things? I work in a hedge fund in London at the moment and there's a massive shift away from R towards python in the algorithmic shops that I know about here. There's also the great work that quantopian are doing on their backtesting framework zipline [1] [1] https://github.com/quantopian/zipline

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.

Did you look at Julia[0]?

It is a Lisp, semantically, with a MATLAB-like syntax (including all the linear algebra sugar), and a LLVM back end.

The stated goal of the language is to give to scienctific programmers the convenience of high level languages for prototyping, yet the speed of low level ones. It has multiple dispatch, based on a powerful type system, homoiconicity and macros (optionally hygienic).

The package collection is growing steadily [1]. There's also a mailing list dedicated to doing statistics with Julia[2].

I looks like a good fit for your project.

[0] http://julialang.org

[1] http://docs.julialang.org/en/release-0.1/packages/packagelis...

[2] https://groups.google.com/forum/?fromgroups=#!forum/julia-st...

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

#88

Earlier quoted context omitted.

What sort of performance baselines would you require?

I have no idea yet. I see you're geeking out in go and there's been a lot of advocacy coming through to look at go as an alternative.

Yeah, Go is a great language. However, I am trying to develop some low level queues that should be faster, and less generic, than the ones that Go provides. But I am having some difficulty putting memory fences into my code.

But if I can get a reasonable level of performance out of the standard Go queues then I will just use those in the meantime.

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

#89
post #75

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.

zygomega, I'm one of the zipline maintainers and we'd love to collaborate with you. There are a few people doing HFT research with zipline, and there's a lot of work to do. At quantopian (my day job), we focus on longer hold periods, so there is room in the zipline ecosystem for you to do HFT. The main benefit we've found with python as the algo language is that it allows for stat programming with pandas, but also OO…

I would see haskell very much as the plumbing side of things. The tools available for handling and reasoning about streams are streets ahead of anything I've seen elsewhere. With zeromq and protocol buffers (that's what we use in our stack) you could very nicely separate the plumbing of the data from its consumption. I'd love to see something like this as well!

How would you handle the position sizing part of the algo if you're testing all days in parallel? Wouldn't the trade size depend on the all of the previous day's PNL?

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

#90
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…

Trading (as in HFT) isn't the same as investing. While the mechanics can sometimes be similar, a trader is different from an investor. What HFT does is segment the market. It's probably best described as a form of arbitrage. Arbitrage is necessary, but in a good market hopefully it is pushed to some form of equilibrium. HFT has an impact on the trading market. However, that doesn't automatically extend to investment.

HFT is like a million tiny trolls underneath the bridge trying to extract their tax.
Post reply on HN