Live data from Hacker News

Case study: Algorithmic trading with Go

polygon.io

151–160 of 311 posts

Re: Case study: Algorithmic trading with Go

#151

One of the most misunderstood concepts about algorithmic trading is that speed is not a critical factor for the majority of systems. My systems like https://grizzlybulls.com/models/vix-ta-macro-mp-extreme have been crushing the market with live trading for 3+ years and yet trade on a frequency of only once ever 18 trading days on average (some a little more often, some even less), and are set up to only generate sign…

How much external data is used for these models or human input/fine tuning on a regular basis?

Re: Case study: Algorithmic trading with Go

#152

Go itself, or any other language won't give you too much of an advantage. What gives you advantage is trading algo, which is always hard to find. I've spent months on figuring out the best parameters for trading. Ended up this working only on historical data, while in reality it was totally different. I could use Visual Basic, and it would be better than Go, Rust, or whatever it is out there, given the algo and strat…

>And for HFT trading a language with Garbage Collector is not a great choice IMO.

Depends. I've heard of places that use Java by creating a huge heap, minimising allocations to almost zero, and just restarting the app periodically before it can fill up. You can achieve very good performance doing this and you don't have to worry about memory bugs.

Re: Case study: Algorithmic trading with Go

#153
post #84

Earlier quoted context omitted.

"they are the more straightforward part to build" More straightforward, heh, sure. But still damnably complicated. Which just goes to show how much money and how much engineering talent is invested in this world that these things are so taken for granted.

So many intelligent people applied for something that has no value whatsoever to humanity regardless of how you look at it.

Facebook Ads are equally valueless.

Re: Case study: Algorithmic trading with Go

#154
When developing an automatic trading system the following aspects are important:

- Data feeds and data ingestion. It can be a fairly independent component which collects data from different sources (might be even discussion forums) making it available to other components in some uniform format

- Feature generation. The source data is rarely used in its original form for decision making and having good (informative) features is frequently the primary factor of success. Moving averages is an example but nowadays this will hardly work

- Signal generation. Here some logic should be applied in order to emit discrete decisions and such models are heavily parameterized with thresholds.

- Real trading and order management as well as coordination of all activities.

The article sheds some light on the technological aspects and the general pipeline used to process the data and manage orders. Although it might be interesting indeed, I would expect more details about how to scale the solution and how to implement it asynchronously. Especially if it uses Go which has a special construct for that purpose - channels.

I understand that it is not the focus of the article, but having some general information about its trading logic and how to plug new and parameterize existing strategies would help. Some links at the end are quite interesting for me because I am developing an intelligent trading bot based on ML and feature engineering (https://github.com/asavinov/intelligent-trading-bot) for which such articles might be quite important

Re: Case study: Algorithmic trading with Go

#156
post #89
post #84

Earlier quoted context omitted.

So many intelligent people applied for something that has no value whatsoever to humanity regardless of how you look at it.

Essentially yes. When I worked in algo trading, it never bothered me that we were extracting profits from the markets, nor that we served little social good. It felt like a step up from where I’d been before (being told that we were making the world a better place, when every engineer knew otherwise.) At least we weren’t making things obviously worse. What did bother me, and was acknowledged by my coworkers, was how…

> We as a society have managed to allocate so many of the “best and brightest” to either fintech wankery or placing ads in front of eyeballs.

Those things have driven a load of proprietary and open source tech that helps everyone else.

Re: Case study: Algorithmic trading with Go

#157

I've been building a bot with Typescript because it is what I know and Python because of the tools available. It is an overwhelming lonely endeavor. With all my other projects, I've always worked on teams, although they have always been very small teams and most of my work was autonomous -- still there was the occasional meeting and stand-ups. I've been working on this for six months and thought about bringing a frie…

How can you hope to compete with the pros? You're not going to be faster than them and unless you have several PhDs in maths it's unlikely you'll come up with a better algorithm. The only way I can think of is to get data that they can't.

Not everything has to be super fast. I was using quantopian to trade based mostly off fundamentals data on a monthly rebalance basis successfully. At least enough to beat the sp500 for a few years- I stopped because I went to a hedge fund that prevented me from trading that frequently and in most small caps. If you want an idea take a look at the piotroski f score and factor based investing. Aqr for example is still largely factor based.

Re: Case study: Algorithmic trading with Go

#158

When developing an automatic trading system the following aspects are important: - Data feeds and data ingestion. It can be a fairly independent component which collects data from different sources (might be even discussion forums) making it available to other components in some uniform format - Feature generation. The source data is rarely used in its original form for decision making and having good (informative) f…

Hey, thanks. Yeah, I agree with you. That's an oversight on my end. I'll tell you here though.

I'm just using go routines and channels to talk between them and then a giant mutex for locking. That's basically it. So, as new data comes in, it builds aggregates (tick based candlesticks) as needed, this then triggers the the BUY logic loop on that new data, if something is detected, that triggers a IB API order. It is dead simple and nothing complex in here. I've had upwards of 100 positions being tracked at anyone time and seems to just work. So, I haven't messed around with complex async logic too much.

I'm actually just hard coding the parameters right into the BUY loop. This probably sounds crazy but for a small setup like this they don't change that much. So, I can run some trades, tweak things, restart, and then test some more. I imagine if you were doing that in an enterprise setting you've have some formal language and hot loading and stuff. But, for me hard coding seems to work well enough.

Re: Case study: Algorithmic trading with Go

#159

Earlier quoted context omitted.

He’s referring to the fact that the HFT “provides liquidity” as in getting a share off your hands and flipping it to someone else that is not you a moment later. This way you didn’t have to wait 3 seconds or 1 minute or whatever to sell your shares because someone knew they could flip them (alpha) on a short notice so they participated in a transaction with you. He’s assuming that without the HFT, the transactions wo…

I don’t have time to reply properly until a few hours from now. In the meantime what I can say very simply in the hope that someone else knowledgeable can contribute earlier. It’s simply an empirical fact that the costs of intermediation to the system are the lowest they have ever been. The US and other global electronic markets are incredibly efficient and deliver unmatched liquidity, information efficiency, and the…

Your dismissals seem to be very biased and you’re not allowing the possibility of being wrong.

As a practitioner who worked on the systems you’re citing I can tell you’re wrong on many fronts.

As far as costs are concerned, you’re not answering the most relevant question that applies to most users of this forum: costs to retail traders, and are only tackling the institutional side of things. Nobody from retail concerns themselves with costs of intermediation because those costs are irrelevant to retail. Not at the order volumes that don’t even incur slippage.

Plus, fees are only part of the game. I can give you an NBBO improvement now to be compliant with the regulation, but I am not guaranteeing anything in terms of price in the next second. See where this is going?

Edit: by the way, what you’re repeating is what I jokingly call a “party line”. Especially if you look at the hard cold data. For example people often cite narrower spreads etc. but even with Interactive Brokers you can get MPID displayed on the NMS aggregated full depth order book and see who quotes how much and at what levels and the spreads don’t add up to the half of the myths people keep repeating. It’s easy to hide the real numbers in the _averages_ and various other statistics though.

Post reply on HN