I just spent the last few hours looking into Google App Engine to use it for trading. Google App Engine (GAE) is a cloud computing development and hosting platform for web applications. GAE is similar to the well-known Amazon EC2 service but it is also very different. The main difference between GAE and EC2 is that GAE is not as flexible as EC2 but it is a lot easier to develop on. Think of it like using C++ (EC2) to write your own trading platform to using EasyLanguage on TradeStation or MQL on Metatrader (GAE). Another advantage for using Google App Engine is that it is free! Well, to a certain extent. It is free for a limited monthly usage. However, Google's free quota is known to be very generous (think Gmail) and this is no exception. Based on the numbers, it looks comparable to a typical \$20/month virtual private server (VPS) hosting package. My guess is that you can run a decent personal quant program on it if you keep the resources for yourself (private use). For more information on the free quota, you can read the current GAE quota web page or the Wikipedia page for GAE. You might be wondering how did I spend a few hours just reading on GAE? The answer is that I've done a brief research, planning, and assessment to see how GAE can be put to use in terms of quantitative analysis for automated and discretionary trading. Without going through all of my notes and logic, here's the gist of my conclusion.

For Automated Trading

Since GAE is also a SDK, it has a restricted programming API. You can't just plug in any custom library of your own (i.e. your broker's API) into your program. That is its advantage and its disadvantage. Furthermore, GAE only support HTTP and HTTPS. So you can't open a socket for your connection either. These limitations won't be changing anytime soon as GAE is designed to be like that for security reasons. Basically, there's no way for your web application on GAE to connect with your broker for trading. So much for that idea.

For Discretionary Trading

Things look brighter for discretionary trading though. A big bonus with using Google App Engine is that it supports the Google Finance API. Google Finance offers free real-time stock quotes. Combine it with the programming capability of the Google App Engine and you have yourself a free number cruncher in the cloud. However, GAE is definitely no match for your personal computer, so why would you go through all that trouble? One possible scenario in which this could be useful is for traders that is often on the road or traders such as myself in which we have a day job. In that case, you can set you quant analytics on GAE as a private web application and then you can access it as a web page anywhere on your mobile phone. One of the obvious limitation with using GAE is that it has limited features for scientific computing. For example, it doesn't support Numpy in the Python SDK. As such, I can't imagine using GAE for anything more than simple technical analysis for now. I certainly hope that GAE can include more powerful scientific computing capabilities in the near future. Until then, I really can't see Google App Engine offering much help aside from performing algorithmic tasks to help with your trading analysis. Their open issues log does announce that Numpy is being integrated into GAE though. So that's a great sign for things to come! I am very hopeful of GAE's potential as a free cloud server to host my quant analytics on. We'll just have to wait for now.

I spent most of 2008 trading futures and developing automated systems on Tradestation. The futures trading didn't turn out so well as I lost 40% of my account and had to call it quit. My quant development work on the other hand, was coming along slow but steadily. However, since I couldn't bear the monstrous maintenance fee anymore at Tradestation, I had to abandon that work. Then last year when I wanted to pick up where I left off on Matlab, I found that I couldn't just continue my work. For one, I've lost most of my files. I think I left them in my other computer in Hong Kong. Which is probably in a landfill by now. Secondly, I didn't keep a thorough journal back then in 2008 like I'm doing now. Lastly, from the important files that I've kept, I didn't bother to convert the codes because I might as well write new ones from scratch than figure out what I did. The reason why I am reminiscing at the moment is because I am finding myself in the same cycle again. As regular readers may be aware, recent events have accelerated my quant projects schedule. I am experimenting with using Metatrader 4 for my foreign exchange trading and scripting in MQL4 for automated trading. Like Tradestation, Metatrader 4 is a trading platform with scripting capabilities. Its programming language, MQL4, is a proprietary language based on C. I took a few hours this weekend to learn it (as I'm familiar with C already). So that I can start coding this week. However, after giving it more thought, I've decided to scale down on my projects with MQL4. I don't want to rely on a proprietary system for short-term convenience. As trading programmers know, the language used is merely a choice. Experience tells me that the bulk of development time is not spent on the actual programming itself. Rather, much of the time is spent on formulating, analyzing, and optimizing your algorithm. So I might as well bite the bullet to build from scratch my automated trading systems and quant analytics on one platform (i.e. on Python). That has been my long term plan all along. Everything under one roof. But I digressed. Then there's the issue of re-useability. Metatrader 4 is forex-only and only works with brokers that support it. As such, I would have to use something else for stock trading. Even for a forex-only system, it would help if I can do intermarket analysis quantitatively. That's not possible as far as I know with MQL4. Which is another major downside for me. To summarize other reasons on how I came about this decision, here are the advantages and disadvantages of using MQL4 versus using a general programming language, such as Python or C++. The advantages of using MQL4 are:

1. Saves A LOT of development time as it's already built for trading
2. Charting, manual and automated trading on one platform
3. Based on the popular C programming language
4. Many forex traders use it
5. Large repertoire of forex-specific programs

Disadvantages of using MQL4.

1. Not for real quant analysis or data mining
2. Limited to MT4-supported brokers
3. Forex trading only
4. Proprietary programming language
5. Must run on Metatrader 4 client terminal
6. MQL5 coming soon

This is certainly a tough choice. Judging by the huge user base, it's evident that many people are satisfied with MQL4. Yet, as I've discussed here, there are downsides to using it (besides technical matters). My current plan remains the same as what I said in my last month's trading review. That is, I will use MQL4 to plug holes in my trading system for now before migrating to build my own system. In fact, I am already brewing my first expert advisor starting today. Perhaps I might even have something to post by the end of this week.

In my previous post, I discussed about [3 reasons why I don't use Jensen's alpha or Sharpe ratio for my montly trading performance measurement][]. In this post, I will talk about what I actually use and how I came up with it. As I was saying in the previous post, what one chooses to use as their performance metric depend on 3 factors such as your style of trading, your agenda, and your interest in this topic. I will briefly lay out my 3 motives as background information. I use a swing trading strategy for trading forex. I aim to hold for at least a few hours to a few days. I am working to hold longer and trade less in the future, but that's another story. To fit my style of trading, a performance metric has to be unbiased for long and short trades as well as taking into account short term conditions in the market. In terms of agenda, what is the purpose of my performance metric? As a part-time trader, I answer only to myself. These numbers are used for my self-improvement and internal month-to-month comparisons only. Lastly, my interest in this topic of portfolio measurement is limited. I want something easy to calculate and simple to understand. I have read a few academic papers on this topic and spent a few hours researching on the web. That's about it. Now that my motives have been laid out, let's discuss my process for coming up with my trading performance metric. Ultimately, my assessment on how well I have done for the month is to measure my return based on the risk taken. In other words, Performance Metric = Reward / Risk. My Reward function is simple. I just steal the idea from Sharpe and use: > Reward = Net Return - Riskless Return Shameless. I know. I don't want to muck with the Reward function because at the end of the day, it is your account balance that matters. The Risk function takes some more thought. On a trade-by-trade basis, the risk taken for a particular trade can be thought of as the stop loss. It is a amount put at risk to be taken by the market. In other words, risk can be represented by the loss you are willing to take. On a month-to-month basis, the most important loss value that I pay attention to is my maximum drawdown. A drawdown imposes a real dent in your account as well as negatively impact your trading psychology. For these reasons, the maximum drawdown is a variable in my Risk function. > Risk = Max. Drawdown ... However, I am not done yet. While max. drawdown is important, it is an entirely internal factor. The risk you take is also affected by the condition of the market. Using the stop loss analogy again, a 50 pips stop loss can be labelled as both conservative and aggressive risk exposure depending on the volatility of the market in the timeframe you're trading. As such, we need to consider volatility in the Risk function. However, this raises another question, what is volatility. Long story short, I just snatch the Average True Range (ATR) indicator that I use on my charts in this formula. However, we can't just stick a ATR value in because it's an absolute number. We need to use a percentage ATR (%ATR) to correspond with all the other percentage numbers in the formula. And since this is for monthly analysis, I grab the %ATR from a monthly chart. In particular, I use the monthly %ATR on the U.S. dollar futures chart. Finally, the Risk function is: > Risk = Maximum Drawdown + %ATR Thus, > **Performance Metric = (Net Return - Riskless Return) / (Maximum > Drawdown + %ATR)** As an example, here are the values I plug in for each variable to calculate my performance metric for [November][]. Net Return = 3.15%, read from November's statement Riskless Return = 0.54% (per annum) / 12 = 0.045%. This is the Canadian 1-year treasury rate in November. Max. Drawdown = 3.55%, read from November's statement %ATR = monthly ATR(3) of U.S. dollar futures / monthly close of U.S. dollar futures = 3.1473/74.895. To verify the efficacy of this performance metric. Let's do a mental check of my criteria as discussed. 1. Unbiased for long and short trades? Yes, it uses the net return regardless of which side you took. 2. Varies with short term market conditions? Yes, from the %ATR. 3. Comparable between month to month? Yes, the number is normalized by market volatility each month. 4. Easy to calculate? Yes, it's can be done in my [trade log][] spreadsheet with a few formulas. 5. Easy to understand? Yes, it's an interpretation of reward / risk. As with any other attempt to summarize trading performance into one single value, many assumptions have been taken. I cherry picked what I needed to assemble a formula. Some observant reader will notice that this formula is similar to the Sterling and Calmar ratios. Indeed, this is yet another modified form of these ratios. In fact, I will be referring to this formula as Sterling ratio in my future posts for simplicity.

As a part-time trader, measuring my monthly trading performance can be as simple or as complex as it can be. On a scale of 1 to 10, 1 being just reading the percent return from the account statement and 10 being running a statistical analysis, my preferred trading performance measurement method is a simple 3. I am lazy but want a metric that is useful for monthly self-evaluation. That is why Jensen's alpha or Sharpe ratio have appealed to me. Both of these ratios are can be easily derived. However, 3 shortcomings of these metrics made me decide not to use them for my forex trading. First is the fact that they emphasize excess return with respective of the market. It makes sense to compare a portfolio with the overall market on a long term basis. But what if you want to do month-by-month, or even week-by-week analysis? Short-term market volatility could skew your performance metric up/down even when you have been performing consistently. Furthermore, what if it is an out-right bear market? Your short-side strategy would be boosted by the negative return of the market. For a swing trader such as myself, a shorter time-frame and long/short unbiased measurements are non-trivial matters for analysing trading performance. Secondly, neither metrics factor in volatility of a market. A 5% return in a calm market is not the same as 5% in a volatile market. If you go out to fish in a storm, you'd better expect a huge payout to compensate for the extra risk. Lastly, I don't like their definition of risk. For me, a short-term performance ratio can sufficiently be characterized as reward / risk. Jensen's alpha calculation has no explicit measurement of risk at all. Whereas Sharpe takes the standard deviation of the portfolio's return as the risk value. For a monthly analysis, I would have to use a daily or weekly drawdown to calculate the standard deviation. The problem with using the daily is that it's too much work for me to do manually on my spreadsheet. As for the weekly, having just 4 weeks in a month is not a sufficient sampling size to calculate a representative standard deviation. In summary, here are my 3 reasons for not using Jensen's alpha and Sharpe ratio.

1. Emphasis on excess return with respect to the market
2. No consideration for volatility of the market
3. Not agreeing on their definition of risk

On the other hand, there are numerous reasons why these metrics are the standard portfolio measurments used by many traders. Heck, Jensen's alpha and Sharpe ratio have been around for 40 years and are still widely in use today. However, they are just not suitable for me as discussed. The thing is, there are countless number of new and old portfolio measurements out there. What one chooses to use depend on various factors such as your style of trading, your agenda, and your interest in this topic. In my next post, I will introduce the metric that I use for my monthly trading performance analysis -- a modified Sterling ratio.