In the example below, we look at another ‘meta’ strategy named StrategyPortfolio which maintains a dynamic portfolio – P – of strategies which it will select from a set of strategies – S – running concurrently in simulation.  The constituents of P as well as their cash allocations and parameterizations will be rebalanced/adjusted regularly after an initial ‘out-of-sample’ period during which only the S strategies are run.

Apart education, the intention of this strategy, as I’d originally suggested here, is to ‘back-into’ a regime-switching strategy without attempting to directly quantify the regimes explicitly.

This has proved to be even more interesting than I’d expected, not so much because it performs particularly well (though it’s promising), but because of all of the things it has taught us.  In particular, the transitions are a killer and there are properties of strategies which (dis-)qualify them from being effective in such a scheme…

bad news good news

As before, I’m not going to take the time to write-up my results in any formal manner but will again rely upon a quick screencast of the software running.  The good news is that I’m figuring out how to edit these things, so it’s mercifully shorter than earlier screencasts…

Please click here to see the screencast.

I hope you find it interesting and will look forward to any comments or suggestions you might make.

Last time we saw an example of historical forward-walking of a portfolio-oriented day-trading strategy which utilized daily data.  This time we do something a bit more interesting and correspondingly complex.  Today we’ll look at a real-time forward-walk of a moderate-frequency strategy (trades perhaps a few hundred times in  a day) which looks at the top-of-the-book but doesn’t use market-depth.  The strategy is a simple mean-reverter that we’ve described before though we’ve had to make some small changes to get it to behave in the context we’re looking at now…

meta-strategy protocol

careful ...

In particular, we need something of a protocol for sending commands from the meta-strategy to the ‘target’ strategy.  Stratparts generally have a simple mechanism for this as they are notified of any changes to their descriptors.  What they do upon such notifications is their own business.  In order to achieve our goals, we might need to firm this up a bit, but it turns out this quickly becomes tricky terrain.

Consider a single contract strategy, say, a simple mean-reverter like one we’ve seen before (and which I’ll illustrate in the screencast below).  If we want to treat it as an element within a portfolio of strategies, then we need to be able to modify its allocation.  But changing the allocation to a dynamic strategy is very different from changing the allocation to a single name within a portfolio as the allocation effectively becomes a maximum and the strategy may spend the great majority of its time under-allocated.  But this is manageable if we don’t mind being under-allocated at times.

A harder case is if someone comes along and says, “stop trading gold”, and “start trading silver”.  What about my open positions & orders?  If the answer is to go flat, then the character (of the returns) of the strategy is itself going to be effected by the fact that they are being mutated by a meta-strategy; if the answer isn’t to go flat then you’re really talking about a whole different, multi-contract strategy.  So you have to be careful to ensure that the kinds of mutations you are relying upon aren’t excessively disruptive to the strategy or you’re likely to see performance wildly different from normal for the strategy.  As always, if you put garbage in, you shouldn’t expect cotton candy to come out…

For this example, we can control allocation and two simple numeric params governing the strategy.  I’m just going to avoid the please-trade-a-different-contract-case and aim to address that issue by ultimately placing these strategies into a portfolio (some later day).  For now, we avoid the hard cases but I think the results remain interesting all the same…

In particular, just as we’d seen last time (on a totally different time-frame and with a totally different strategy), the forward-walked strategy appears to perform well relative to its peers…

If interested, please click here to see the screencast/example.

-

Happy Thanksgiving!

'optimization' or 'search'?

We’ve been looking at how a strategy container might view and implement a variety of modes for strategies it will launch and contain.  Last time I documented a uniform initialization process for many of them, including a posited walk-forward parameter optimization mode.  I’ve implemented an initial version of this that I’ll illustrate through a screencast (first ever – be gentle) below, but before continuing want to raise a couple of cautionary notes about the slope we’re traversing here.

From the very first post on this blog I’ve tried to underline the danger that over ‘optimization’ poses in view of the simple unalterable fact that if you look at enough random junk, you are bound to see things that look impossibly good.  Doesn’t mean they’re actually good.  In the context of trading strategy development, this is a particular danger as strategy parameter optimizers are easy to come by and can be very misleading if employed naively.  I think this is in part due to the term ‘optimization’ which is really a stretch for what these tools do.  They’re better described as search tools as they are really searching through a tuple-space of possible parameter combinations that you’ve specified, and then ranking them by some criteria you specify.

They’re still useful, but less as ‘optimizers’ and more as tools for judging the sensitivity of the strategy to different parameterizations.  If the strategy demonstrates good performance and stability over a variety of market conditions and parameterizations, you may just have found yourself a winner…

Anyway, I felt that had to be said…

Now, I’ll open the floor to a quick illustration of the initialization process described previously and an example of historical forward-walking.

At this point, I’m vested in the inquiry we’d started with the regime-switching post and will apportion time each week towards implementing something like what we’d described there.  I expect the steps to be something like:

1. historical fwd-walking which I’ll illustrate today
2. real-time fwd-walking, that is, dynamically adjusting a live strategy’s parameters based on a continuously repeated ranking of a concurrent ‘live optimization’ of the same strategy
3. real-time allocation to a portfolio of strategies based on regime-switching where regimes are defined by the performance of a heterogeneous set of strategies we run concurrently (again ‘live optimization’)
4. peace on earth

I may have some of the steps wrong, but am hopeful.  We’ll adjust as needed.

If interested, please click on the below image/link which will hopefully take you to a screencast.  This is my first-ever attempt to put a screencast in the blog, so please let me know if you have technical difficulties or suggestions on how to improve the experience.  Or if it’s just a big waste of time!

In the screencast I give a quick illustration of a simple backtest, a simple parameter optimization and finally a fwd-walk.  I’ll appreciate your feedback.

>click<

poor Jorge wasn't ready...

In this post I’m going to revisit some of the topics discussed in the recent ‘containing a strategy‘ and ‘multi-strategy trading with regimes‘ posts, focusing on the process of assembling a strategy and its context in preparation for its launch into any of a variety of modes.

I recently realized that – from the perspective of a strategy container – the process of walk-forward testing is remarkably similar to the regime-switching model we’d discussed previously.  Up until now, I’ve employed walk-forward testing in an ad-hoc manner by taking an existing strategy and then writing a little driver very much like a unit-test scaffolding which would walk the strategy forward, permuting parameters based on previous performance.  Not a general solution, but straight-forward as I employ the strategy parameter optimizer from stratbox in this kind of a toolkit use-case.

I sat down to write one of these walk-forward scaffolds yesterday and started to think about how I could generalize the solution and roll it into stratbox’s GUI and it occurred to me that I could likely kill two birds with one stone…

walk-forward testing

–

I imagine there are different ideas/implementations of it, but for me walk-forward testing is the case where you are using repeated historical parameter ‘optimizations’ to dynamically modify the parameters on a back-tested strategy.  For example, say we have strategy X with parameters p1 and p2.  Let’s say we want to walk-forward test it from the beginning of the year until now.  We’ll need a look-back period for optimizations – say 20 trading days – and a frequency with which to apply the results of our optimizations – say every 5 trading days.  So, on a weekly basis we’re going to look back at the prior (rolling) month performance and adjust our parameters to match the best performer.  How you define ‘best’ is your business but I’ll use something simple like sharpe here.

Continuing with our example, we’ll say that p1 will be permuted 3 ways with values from { 1, 2, 3 } and p2 will be permuted across 4 values { “a”, “b”, “c”, “abcd” }.  So we have a basis of 12 strategies for optimization and we’ll call these O1…O12.

To perform a walk-forward test on X from 2009/01/01-now, we will begin a parallel back-test on O1..O12 starting 20 trading days before Jan1.  On Jan2 we will look at the prior ~month’s results and pick the strategy who had the highest sharpe ratio and clone him and start testing him “walking forward.”  Each week, we’ll repeat the process except that instead of cloning the winner as we did the first time, we’ll just make sure his params are the same as the new winner’s params.

Repeat this process until ‘now’ and you’re done – you’ve performed walk-forward testing on X.

–

Let’s think about what’s happening here.  There are 12 strategies running from ~2008/12/1 and another strategy running from 2009/1/2; all strategies run until now.  There’s also the activity that “we” have done during this process.  What we are doing is the role of a meta-strategy just as we’d seen in the regime-switching case.  The walk-forward meta-strategy needs to watch a set of ‘optimization’ strategies and permute another target (“X marks the spot”) strategy on a regular basis to match parameters with the prior period’s winner.

differences vs. allocating to strategies with regimes

Let’s imagine that we’re going to take the 13 lovingly-named strategies O1…O12 and X, along with the newly revealed meta-strategy we’ll dub “M”, and put them onto a live environment instead of a historical back-test.  Suddenly we’re pretty close to what we’d described previously.  The biggest difference is just the temporality of the strategy context: historical or real-time.  Another difference is that O1…On (let’s generalize just a bit) are no longer necessarily all the same strategy – they may be completely different. X is also no longer a strategy, but a portfolio of strategies:  a replicated subset of O1…On we’ll call X1..Xm.  “Best” is no longer a unary choice but must be rich enough to allow M to support some kind of an allocation algorithm across the X family.

OK, so there are some significant differences.  But from the perspective of the object model on which all of this can be implemented, the differences may be limited enough to warrant tackling together.

ready to launch

Before looking at the workflow of a strategy launch, let’s consider all of the various modes we support with our design:

• Historical: back-test single strategy
• Historical: parameter-based optimization of strategy (decomposes to many back-tests)
• Historical: walk-forward testing of strategy
• Real-time: SIM – run single strategy with real-time market data and an exchange simulator
• Real-time: LIVE – run single strategy with real-time market data and a live connection to OMS/broker/exchange
• Real-time: LIVE+SIM – run two cloned instances using the same market data, but with one routing orders to live venue(s) and the other to a simulator.  This is mostly useful for the development of a simulator or to evaluate the quality of simulation for a given strategy.
• Real-time: optimization – run many strategies, permuted differently across live data but routing to a simulator.  I don’t know what this is useful for, but I find it entertaining… The screenshots from the regimes post were illustrating this mode.
• Real-time: meta-strategy – our mythic regime-switching allocator will be a nice example of this mode.

-

Consider the following sorta-flowchart illustrating the preparation for launch of a strategy.

click for larger version...

The process has 4 or 5 stages depending on whether we’re being “meta” or not – that is, if we’re using optimization of any sort.  The highlighted parallelograms are the concrete end-result(s) for each of their respective steps.

• Assemble Strategy Context – The basic channels of I/O for a trading strategy are its sources for market data and the exchanges where trades can be executed.  The MktDataSrc and ExecutionPlatform abstractions need to be specified.
• Assemble Strategy – Whatever mode we’re looking to employ will require a strategy either to itself go and trade for us or else to serve as the seed or prototype for our activities.  In this step we define that strategy.  For me, this can be a composite process as a strategy is made up of an arbitrary number of stratparts.  The assembly of a strategy can be done manually with a gui or by loading a strategy from a file or other store.  Once the parts are identified, they can be bound together to form a strategy instance.
• Configure Strategy – Once assembled, the strategy needs to be configured.  This may just mean we need to parameterize it appropriately for our use.  If we’re being meta and require optimization then we’ll also need to describe the parameters to modify and the ranges for each.  This gets boiled-down into an OptimizationDescriptor which is composed of a prototype strategy and the parameter/range data required to perform the requisite back-tests.
• Configure Optimization or Meta-strategy – If we’re not running an optimization or utilizing a meta-strategy, this step is skipped.  Otherwise, this is where the optimization and/or meta-strategy should be built and configured.
• Review & Launch – Anytime you might loose a piece of software on an account with real money in it, it behooves you to pause and reflect for a moment.  Now is that moment.  If, after that moment of reflection, both you and whatever risk measures you employ agree that it’s OK, then it’s time to launch.  Happily, this is easy because we now have everything we need.  Again, the meta cases are a bit more involved as the strategies to be optimized or managed must be first generated based on the optimization descriptor we’ve inherited from earlier steps.  Then it’s a matter of assembling the pieces previously selected and configured and away we go.

-

Anytime you might loose a piece of software on an account with real money in it, it behooves you to pause and reflect for a moment.  Now is that moment.

I was taught that writing software is easy if you can express the problem you’re looking to solve and its solution in clear and precise English.  I’m not sure about this being grammatical, clear or precise, but hopefully it’s enough to illustrate a means of uniformly modeling and implementing these beasties across a variety of use-cases.

For me, at least, writing this description is helpful as it forces me to walk through the various twists and turns in some detail before digging into the code.  When I get the integrated walk-forward testing working I’ll try to provide some illustration of its use and will look-ahead to developing a regime-switching example using the models/mechanisms we’ve been discussing.

Even if it’s hard to find good stuff, one must still look as there’s always more information that can help you than you can effectively process or retain.  A few weeks ago I was trying to formalize the expected profit function of an algorithm I’m developing and wanted to see what people had written about the topic.  I entered ‘define profit function for trading algo’ into google and was pleasantly surprised to see a paper entitled ‘Multi-strategy trading utilizing market regimes’ by Mlnarik, Ramamoorthy and Savani.  It doesn’t directly cover the topic I was looking for, but instead addresses a number of related topics I’ve been interested in for some time:

• the treatment of a strategy as an instrument in its own right
• composing portfolios comprised of strategies
• using regime switching techniques to manage portfolios of strategies

In this post, I’ll briefly review their paper, illustrate how one can easily model strategies in relevant ways using the strategy ‘object model’ I’ve described previously through an example, and conclude with some thoughts on how these kinds of strategies might be implemented and further explored.

‘Multi-strategy trading utilizing market regimes’ by Mlnarik, Ramamoorthy and Savani

Their paper begins:

This paper considers the problem of dynamically allocating capital to a portfolio of trading strategies. The allocation should be robust, and the capital allocated to a trading strategy should reflect the confidence in the expected profit that the strategy will make in current market conditions.

Good trading strategies exploit recurring market dynamics that can be more prevalent in some time periods than in others. Indeed, the concept of regimes is fundamental to financial markets, and much research has focused on the detection of regime shifts. In this paper, we consider a regime as defined by a set of trading strategies that exhibit similar performance in a given time period.

We consider different parameterizations of the same strategy as distinct in our ground set of strategies. The trading problem is to pick a distribution over the ground set that will achieve good performance in the current time period.

They start with some interesting definitions.  A trading strategy is defined as a function which takes a given market State and generates a convenient Answer “denoting all possible trading decisions”.  Strategy functions can also be parameterized and different parameterizations of the same function/strategy are viewed as distinct qualitative strategies.  They assume the existence of  the set of all strategies.  A regime is defined as a set of trading strategies who behave similarly over a given period of time where similarly is measured by the variance of a fitness function.

So they start with a set of strategies, a fitness function and some historical market data or state, and their first task is to identify the regimes.  They do this by running the strategies against randomly selected partitions of historical data, quantifying their respective performances with the fitness function and identifying the clusters deemed statistically significant.  Those sufficiently significant and similar sets of strategies are themselves the reasonable regimes while the set of strategies within all the reasonable regimes are themselves dubbed the reasonable strategies – the candidates for execution.  This might sound strange, but as I’ll illustrate with a concrete example below, this is actually a pretty effective and even intuitive way of defining regimes.

They define function stFuncDist as, for any regime, generating a distribution or weighting of the strategies within the regime. While classifyMarket is a function that generates a distribution across all regimes for any given market state. Both models can be “trained” and they do so by again iterating randomly across chunks of historical data adjusting the weighting constants of these two functions.

Finally, it’s time to trade and they can effectively use classifyMarket to determine a predominant regime and allocate capital as indicated by stFuncDist to the appropriate set of “reasonable strategies.”

They claim to have utilized this technique to generate the results charted in Figure 1, but they give little detail on the initial universe of strategies.  I believe they had one strategy which was parameterized into a set of qualitative strategies and run across one market, the CME’s Nasdaq emini.  I have no reason to doubt that they had exactly this result, but without more details on what they actually did, it’s hard to view it as very meaningful, though it certainly is suggestive.  An interesting thing about how they present their result, which I’ve seen in other academic papers, is that because they’ve precisely defined the set of possible strategies they look at, they can also calculate max and min possible returns over the relevant period.

Figure 1: Out-of-sample profit (middle line) versus possible min (bottom line) and max profit (top line) over all strategies for the period 2006-11-01 to 2008-08-28.

The paper continues with another section, but I’m going to stop my overview here as the last part is less interesting to me and the interested reader should of course read it themselves.

complex strategies or simple strategies combined

One of the broadest design questions I see for the development of effective trading algorithms is whether one should employ complex, customized algorithms or instead utilize simple algos which can be simply combined to produce emergent complexity.  Although the authors of this paper allude to “Good trading strategies”, I wonder if one can even forget the “good” part and instead worry about applying – even bad! – strategies at the right times.

There are a lot of things I like about this paper, but probably most of all it’s their definition and use of a regime.  One of my first posts describes a pair of strategies – a simple mean reverter and a simple trend follower.  These two strategies are about as dumb as you please.  And yet, their behavior is pretty interesting apart the observations I’d published at the time regarding the distribution of their returns.  During the trading day, I’ve taken to running those two, old, dumb strategies across a variety of markets in simulation mode.  Why?  Because it’s easy, costs me nothing and actually is pretty interesting in that the strategies really do cluster in the way Mlnarik et al describe, effectively partitioning the market into visible regimes.

a simple example: identifying regimes with strategies

In order to illustrate this, I created a desktop within stratbox onto which I ran these two qualitative strategies parameterized differently and across six different markets.  In total, I have 48 strategies running with 24 of the mean reverting (MR) variety and 24 of the trend following (TF).  In figure 2 and figure 3, they are sorted by qualitative strategy – all of the MR strategies followed by all of the TF strats.   In figure 4, they’re instead sorted by instrument at the end of the day after all of the strats had been rendered quiescent for the night by their schedulers.  You can click to see a bigger version of these screenshots.  On each, the left side of the screen shows simple charts of the relevant markets while the right contains a table in which each line item is a running strategy.  The first is at the beginning of the day. the second is shortly before going silent at 4pm and the third is shortly after 4pm.

Figure 2: variously parameterized MR & TF strats run in realtime+simulation mode. Sorted with the MR strats first. (click)

Figure 3: later the same day

Figure 4: at EOD, now sorted by instrument

You’ll note that at all times throughout the day, the MR and TF strategies effectively mirrored each other regardless of market.  Although I’m not going to illustrate it, I’m going to just go right ahead and assert that this is almost always true  based on what I’ve seen.  And this is at the heart of the paper’s authors’ insight regarding regimes – they can be effectively identified by examining the performance of even simple but well-defined strategies.

This suggests a simple means of implementing a similar design to that they described right on top of this example I’ve put together.

modeling meta-strategies

We need one more element to manage all of this – a meta-strategy – that is, a strategy for managing other strategies.  We support this idea in stratbox with what we call a controller strat.  The cannonical example of a controller strat is our implementation of the (Don’t) Panic button (the bright red button with an ! in the upper right hand corner) which will get all strategies out of the market with varying degrees of urgency and finality.  This is implemented as a controller strat which injects a stratpart into all running strategies.  The injected stratpart first deactivates its peers and then cancels outstanding orders and then gets out of the market with whatever urgency the user has required.

allocating to portfolios of strategies

In my example above, I have 48 strategies running in simulation across 6 futures markets.  Let’s imagine that at any moment in time, I will always have at least one strategy of each type (MR and TF) running for each market. Thus, I’ll always have 12 live strategies running against real money accounts and 36 candidates running against a simulator.  Effectively, we’ve just described a portfolio of 12 elements where each element is itself a strategy.

It’s not difficult to imagine implementing a controller strat which on a regular schedule will simply adjust the parametrization of the running strategies and their allocation of cash based on the performance of the strategies running in simulation.

It’s not difficult to imagine, but implementing it inevitably poses a variety of challenges not least of which is finding the time!  For now, we’re still finding new and interesting ways to express strategies which deal with portfolios of exchange-traded instruments.  But I think that this is just a point on our technology’s maturation curve which will ultimately lead to the regular development of strategies which operate on portfolios of strategies themselves…

Anyway, it’s nice to see a bit of academic work formalizing what I expect is a natural step in the evolution of trading algorithms.