Saturday, 22 December 2018
Tuesday, 27 November 2018
Last week I gave a talk at the Google Developer Group in Reading about some work I've been doing investigating the possibilities around using machine learning to drive an automated trading platform.
The talk walked through the basics of reinforcement learning, technical analysis and the basic ideas behind trading for a profit and some ideas around using technical analysis in feature engineering for the model and how to architect a system as a collection of microservices processing messages from PubSub to predict on live data and execute trades.
One of the key problems touched on was how an unfiltered stream of data from the trading platform means that trying to potentially classify trends as 'good' or 'bad' means that small mistakes incur the costs of buying and selling and the bot can end up thrashing it's account balance away.
But the main problem that makes reinforcement learning ineffective when employed in a straightforward manner to automated trading is that RL learns that an action causes a transition between some state to another, which is why memories are stored as State, Action, Next State, Reward. The agent however, is never actually affecting the state of the system. The state is the same whether we buy, sell, do nothing, or close a trade that's successful or otherwise.
As such, because of the limited number of actions possible, the training can be unrolled into a simple standard learning problem where you potentially predict the 'reward' of an action on a specific state.
After picking apart the data and using principal component analysis, I saw that there was so much overlap between the states where it was profitable and unprofitable that they were indistinguishable in the dataset that I examined (ETHBTC for the previous 12 months at 1H candles, using a variant of crossover as the entry points and looking to sell around 10 hours later).
It makes more sense in retrospect, that this problem would be better approached by finding a passable simple strategy and then using machine learning to try and reduce the number of unsuccessful trades. However the process was useful in learning how to engineer features, construct models, run them in production, and the techniques to assess their accuracy and suitability.
Saturday, 13 October 2018
At Hu:toma we're very much all in on Google Cloud, so it was great for the engineering team to be able to head over to Cloud Next this week and find out what's new. I somehow through random chance managed to get an unobstructed view from the second row (first row was reserved for Googlers) for the keynote, which made up for the obscenely early train to attend.
The venue was as meticulously decorated as you'd expect, with an upper floor demonstrating google products and accommodating talks, while the downstairs provided more of a breakout area, more vendors and the keynote room. It was interesting to see a TPU up close, albeit a much older one than is current.
We did compete to see who could pick up the most random swag, but a colleague ran away with it. There was a great demonstration from Thompson Reuters on pulling tick data and doing some simple filtering on it, and walkthroughs of some improvements to Tensorflow that improve the interface and walk it towards the user friendliness of Keras. On the second day I didn't feel like getting the pre-drawn train again so had a slower wander in to enjoy the improved weather.
The Milton Keynes GDG hosted their December meetup at The National Museum of Computing inside Bletchley Park. We had a detailed demons...
This post might get a bit more context next week, but essentially, in continuation of looking at data structures in F# and C# I picked prefi...
Containers are a topic that have been rising in occurrence for me, for the last year or so. From using them as part of the architecture at ...
While everything was being mixed into the same chain of plug-ins individually, we did at least know that mastering should be a clearly defin...