So just to give you all a brief update and let you know I haven’t abandoned my blog. Moved over to London as you might know, and just finished the first two (induction) weeks at my new school.
A lot of stuff going on, a lot of interesting people and new friends 🙂 So basically haven’t had time to write anything new yet. And as school starts off for real now on Monday, my days will undoubtedly continue to be filled up quickly. But I should non the less have time to write a thing or two each month.
In general I view this book as an intro book. It eases the readers journey by starting out with the evolution and business aspects of HFT, before diving into the more technical parts. It also has a metric ton of references throughout the book for those interested in a deep dive.
I do have a low frequency trading system up and running, so based on that I would recommend this book to people interested in both high and low algorithmic trading as there is definitely a lot of cross interest. Chapter 5 for instance, “Evaluating Performance of High-Frequency Strategies”, covers techniques like Sharpe and Treynor ratios, Jensen’s Alpha and a buch more. These are topics of both high and low frequency interest.
Another chapter I particularly enjoyed was the Risk Management chapter, giving the reader a buch of hands on and practical examples on how this can be performed.
Chapter 15 covers back-testing of trading models, basically divided into two types of strategies: Point forecasts and directional forecasts. What I find very strange about this chapter is how directional forecasts are evaluated. In essens, in addition to a stop-loss level, a take-profit level is also put into each signal/order. Now in my world, adding a take-profit to a directional forecast would change that forecast to a point forecasts. I see the benefit of having a stop-loss, but unless that is triggered I do not believe a directional forecast should be closed till the direction (trend) changes. Of course there are operational benefits of using a take-profit (in addition to a stop-loss) level for each order, basically making them a fire and forget type of order, but still, IMO, directional forecasts and their orders should be just that, directional.
All in all I would recommend this book to anyone interested in an introduction to HFT, tips and references to further reading. As said, I would also recommend this book to anyone doing algorithmic LFT. There’s so much crap being said about HFT, so it’s good to get some pure facts on the table every once in a while.
Two people, a day trader (Svend Egil Larsen) and a student (Peder Veiby) have both been prosecuted with stock price manipulations. According to the article they have not known each other or cooperated.
There are around or over 2200 transactions in total, and their counterpart have been a trading bot operated by Timber Hill.
Both traders have made a profit on their trades, performed in relatively illiquid shares, listed on the Oslo stock exchange.
Between November 2007 and March 2008, on several occasions, ranging from 30-40 to under 200 transactions have been performed over a few minutes to a few hours (less than a day).
So what is this? Socialism on a stock exchange? Poor bot owner, who had a non-optimal sub-performing algorithm that lost them money? Or are the people at Oslo stock exchange just not getting high frequency trading, or not liking it? Or are they loving the high volume that algorithmic trading might bring them so much that they try to protect the big fishes?
This whole thing sounds a bit strange to me.. I guess you can say that the two people being prosecuted here don’t fit under the typical HFT definition. But I ask; what’s the actual difference between what they have figured out and performed manually, and what you have figured out and made an application/automated strategy perform on your behalf? And for all I know, they might have had automated routines helping them out. Unless there are some key elements left out in the article, the behavior of the Oslo stock exchange is both strange and unpredictable as far as I can tell.
I guess the moral of the story is: If your doing HFT, think again before you bring your money/liquidity to the Oslo stock exchange. That is, unless you’re loosing money, because then maybe the Norwegian authorities will fight your “case” for you.
Scott Addison sums it up quite well with two words: trepidation and optimism.
As I’m preparing for London, selling my apartment, giving away or selling most of my stuff, my car. Packing up my beloved stereo; I’m addicted to music, and good music requires a great stereo. It’s close to complete now, just about a month before I head over to London. I’ve always said that I only move from one city to a bigger one. That’s true ones more, as I move from Oslo, Norway, to London. I sure also hope it’s a greater one..?
None the less, it feels good. Finally moving on again. I’ve always “rebooted”, started on something new, leaving things behind every 3-5 year the last 10-15 years. That’s basically half my life, and it has always turned out to be a good decision.
I expect this to be the same, as I’m leaving for Cass, starting on something that has been a keen interest of mine for quite some time now. But the stakes are higher this time. I’m older, and I’m leaving a good paying job with an offer for an even better paying job. I’m actually not expecting to earn as much as I currently could just after finishing Cass, but I do expect to make that up again after a few years. Also, some times passion must prevail 😉
Looking forward to one intense and interesting year, meeting new friends, extending my network. And let’s not forget, it’s only about a 2-3 hour flight between London and Oslo, so all my good old friends will not be forgotten!
A few years ago (during my first attempted venture) I was creating a Microsoft MSN Messenger client for regular feature phones (with Java ME.) And part of what we did was to create a proxy that we ran on a server. This proxy basically translated the MSN Messenger protocol into a purpose built protocol for the client we were developing. There’s a ton of good reasons to do this; The phones at the time didn’t handle many simultaneous connections very well, and connections were also often dropped. So we needed something that would take all the MSN Messenger connections pr client, merge them into one optimized connection and also tolerate a few seconds of disconnection/reconnection every now and then.
The other horrible thing about developing for feature phones back then was the crappy support for socket connections. Often, the network operator would only allow a HTTP connection through their own proxy, so we also needed to support long pooling over an infrastructure that didn’t really support it.
Anyway, the point that started making me feel that good cozy warm feeling when watching the video was when I started thinking about how much easier it would have been to create that proxy using node.js.
Sure, we could have used blocking IO, and dealt with the scalability issues later on. But as sure as we were about the coming success of our client, non-blocking IO was the way to go. Dealing with partal reads, thread pools, sessions (remember, we needed to tolerate dropped connections) and all that was not very fun. Far from as fun as it is creating web apps with modern JS libraries.
And, this is where node.js might come to the rescue. Sure, it might be very early right now, but give it some time and a few killer frameworks, and maybe even back-end server programming will become just as fun as front-end browser programming. And looking at the future trend of web apps, with long pooled HTTP connections and WebSockets, tools like node.js is essential.