Live data from Hacker News

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

scarcecapital.com

91–100 of 198 posts

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

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

Hi fawce, I'm a big fan of quantopian but didn't realize that zipline was a separated project. Will have a good scout around the project and see what you guys are up to :)

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

#92

Earlier quoted context omitted.

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…

The algo is only one part of a real trading organization. Granted it's the one that gets all of the credit, and is perceived as the sexy side but operations and reporting is easily as important. If you had the best algo, but you kept making mistakes or mis-reporting because your platform was crap, you'd be out of business as fast as if your algo didn't make money. I'm talking here of hedge funds where assets under management are all import and generally external. It might be a different story in a market maker or prop shop where getting research into production fast is all important.

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

#94
post #87

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.

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 packag…

yes. Julia looks like a quality language but suffers the usual new kid on teh block hassles - very few packages so you have to spend too long rolling your own.

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

#95

Earlier quoted context omitted.

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…

I've had a quick read through the .org file now and it appears that you're using R for things like moving averages over the stream of prices. Have you considered using one of Haskell's FRP (or pipes/conduit) libraries for this side of things?

definitely. I intend to move all of that code into haskell once I get a handle on whether the algo design is on the right track.

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

#96
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 mean of the bid and the ask, generally. For a daily close price it can be a fifteen-or-so minute average thereof.

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

#97
I have no experience in the financial industry, but HFT has always fascinated me as a potential source for very high rates of "events". Could you share your general insight about the sheer volume of data that commonly gets pushed through an HFT system? I'd also be terribly interested in a multi-megabyte/gigabyte "recording" of HFT trade data.

http://www.nyxdata.com/capacity

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

#98
post #79

Earlier quoted context omitted.

Couldn't the infrastructure be open source while the specific trading algorithms kept closed source?

This could be a lot more fun than classic codewars. For 99% of the "system" there's no particular reason you'd have to connect to the NYSE and trade real stocks for real money. Looks like they're feeding from iqfeed, but I think it would be huge fun to create an imaginary competition exchange, convince about 100 algo writers to compete, and shove them up against each other purely for the fun of it, see who's a better…

I like your thinking V, and that's not too far away from one of our ideas. Take some algos that are representative of typical market makers and trader behaviour and fit the parameters so that the simulated trading starts to look like the live data. Maybe it's a better idea to use real algo makers.

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

#99

Sorry to burst your bubble but high-frequency trading is only viable and necessary for market makers. The end result of any type of algorithm you think of is always a curve-fitting function of existing data.

No need to apologise - curve fitting is a big issue. But I would think that everything that happens on kaggle would be curve fitting by your definition right? And how is the stuff that happens in brains something other than curve fitting? It's how you connect the data dots and what you choose to focus on that makes the difference.

You are asking how the human brain works, that's a whole different issue and I don't know what Kaggle is/does.
Post reply on HN