Back to Community
OLMAR with Universe

This is an update on the OLMAR algorithm Grant and I have been working on over the last couple of months. We've been continuously updating and fixing bugs. I now went over the whole logic in detail and am highly confident that the implementation is correct.

The idea of the algorithm is that if a price of a stock diverged from its mavg, it will eventually revert to it (i.e. mean reversion). The portfolio is rebalanced in accordance to that. In more detail, the algorithm is finding the optimal portfolio weighting to maximize profits under the mean-reversion assumption. By doing so, the algo essentially implements a follow-the-loser strategy.

Secondly, this now uses the new set_universe() feature to remove selection bias. The algorithm needed to be changed a little bit to adjust for the changes in portfolio size which adds some complexity. Another problem is that the portfolio does not take into account that the sids can change. Maybe for each quarter the portfolio should be equally rebalanced? In any case though, this is a great feature as one can't just chose AAPL and go to town. I think it leads to more honest backtesting.

The paper describing the algorithm, which is one of my favorites so far, can be found here:
After thinking long and hard about it, there is actually a very nice intuitive understanding of what each term does. This previous paper goes into more detail about the intutions (the algorithm is not the same but the ideas are very similar):

There is a previous thread with discussions with the author of that paper here: (note that this implementation contained a bug).

Ideas for improvements:
* Change mavg() to vwap(): high-volume stocks tend to be more volatile and the algorithm is prone to invest more into highly fluctuating stock.
* Change eps parameter: This is a critical parameter that adjusts how aggressively the portfolio gets rebalanced. Values closer to 1 are more conservative while a value like 5 leads to an allocation that puts everything into one basket.

Clone Algorithm
Backtest from to with initial capital
Total Returns
Information Ratio
Benchmark Returns
Max Drawdown
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Information Ratio 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 5130c25b48867f0876d60954
This backtest was created using an older version of the backtester. Please re-run this backtest to see results using the latest backtester. Learn more about the recent changes.
There was a runtime error.
10 responses

Thanks Thomas,

I would also add, as a potential improvement, the so-called "BAH(OLMAR)" modification described in:

Effectively, it removes a potential bias of picking a fixed trailing window length (e.g. above, you use mavg(5)).

Additionally, a weighted moving average could be considered (e.g., so that more recent prices are favored over older ones.


Looks really good!

The first question that came to mind is: why does the performance trail off? It makes a huge gain in the first 6 months (2008 was not a good year) which is then never seen again.

Hello Thomas,

I see the same problem with this one (see my comment) soon as you start trading, the CASH should remain ~$0, but it is not. Also, did you modify the algorithm intentionally, so that you no longer keep all of your money in the security portfolio (market)? My interpretation of the OLMAR algorithm, as published, is that it should re-allocate only amongst the (hopefully mean-reverting) securities, and not go to cash. It appears that you allow the algorithm to pull some/all of the money out of the market...right?



I tried running your code above and got this error:

9 Error Runtime exception: TypeError: init() got an unexpected keyword argument 'delay'


Grant, I think the latest and greatest OLMAR implementation is OLMAR 3.0

Thanks Dan,

I just wanted to flag an apparent backwards compatibility issue with the slippage settings. Has 'delay' been removed?


I'm frankly not sure when that stopped working - I don't think it was ever a part of the documented slippage function. Thomas, of course, has insider knowledge and sometimes uses functions that aren't out and supported.

If you'd like to have a delay in your slippage, you can do a custom slippage model, too.

I do remember implementing this but I'm not sure what happened to it, sorry.

In any case, you should be OK just removing that option. Personally I like to start with a backtest that has all the complexities of order execution removed for debugging purposes, that's why it's there.

Runtime exception: TypeError: init() got an unexpected keyword argument 'delay' (Line 9)

Isaac you'll get better progress with the most recent version of the OLMAR implementation at OLMAR 3.0