steppin’ out

November 25th, 2009

We’ve been looking at what we’ve been calling “meta-strategies” – strategies that act upon other strategies – with the goal of implementing something like we’d described in the recent regime-switching post.  (Please note that since then I’ve added a category to capture this thread.)

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!

EMS Internals, regime-switching, strategy development

  1. MAF
    December 4th, 2009 at 14:49 | #1

    Dear Tito,

    Congratulations on your blog, its of a great quality, it truly shares insights I hardly see in the street these days ( or any for that matter). I wish there were more quorum! any way after reading your posting history, here is my feedback.

    To potentially enhance your back testing methodology

    Use importance sampling

    This methodology is typically presented as a method for reducing the variance of the estimate of an expectation by carefully choosing a sampling distribution. In this case, each of your individual strategies can be considered as an stochastic policy that have a non-zero probability of taking any action (buy, sell, do nothing) at any time ( upon the state or regime of the market in your FWD-WALKING)

    Policy evaluation is the task of estimating the expected return of a fixed policy.

    Every policy induces a probability distribution over histories ( here you could add an ABM simulated price or many).
    Then the probabilities associated with the policy combined with the probabilities of the envi-ronment will produce a complete distribution over histories. The returns are a deterministic function of the history. Therefore, we desire to calculate E [R(h)[X] where the expectation is taken with respect to the history probability induced by the policy X.

    Because each X is potentially different, each h is drawn according to a different distribution and so while the data are drawn independently, they are not identically distributed.

    As an added filter and once you have run your fwd-walking, Try incorporating an heuristic to find the trends of each strategy’s P&L in the history of the last year, with the intention to allocate funds into the losing ones and retreat from the profitable (yes I know it`s backwards), since the classifier will pick up the patterns at which some of the strategies will stops being profitable and or start being losers. Once you get the time laps and IDs of these profitable strategies, you collect them and re run a second FWD WALKING. allegedly the ones that are able to find the abstracted inefficiency will show up as the more robust strategies.

    Regarding the database you were looking for managing high frequency terabytes. have you considered

    RMD Server™ from modulus? I haven’t tried it but some guys over a prop group mention it.

    Regardless of which solution you end up looking for, I would argue that you would want to include a PSF (parallel file system) as it truly increases the reading and writing of thousands of files (symbols) in tandem.

  2. December 5th, 2009 at 06:27 | #2

    Hi MAF,

    Thank you for your kindly words and especially for spending the time to share your observations and ideas – they’re greatly appreciated.

    Although it seems standard and may well be the correct way of reasoning about such things, I generally resist representing a strategy as a state variable like that you describe (buy|sell|hold). The ‘hard’ reason is that it doesn’t capture the important sets of multi-contract strategies or strategies that are simultaneously looking to buy and sell with limits (like the one in this example); and the ’soft’ reason is that it doesn’t jibe with my intuition. The former might be resolved by introducing richer states, but the latter might well require reverse brainwashing at this point!

    That said, your suggestions are creative and welcome. Honestly, it will take a good bit of research for me to fully appreciate them as I tend to learn empirically and I’m not familiar with all the techniques you highlight.

    Your comments about applying some form of policy evaluation, and in particular your mention of using agent-based reasoning are also great – if non-trivial! – suggestions. There are always so many different and individually interesting approaches to explore.

    As for the taq/tick db, I had heard of that product you mention, but by now am pretty firmly committed to maintaining and further developing my solution as having an end-to-end stack for analysis/development/execution remains a desire near+dear to my heart. I agree re: the PSF, but am currently thinking that the way to acquire it is by sticking my terrabytes into a cloud and using hadoop to
    implement a seriously scalable simulation environment… yet another compelling avenue to explore. In the meanwhile, what we have is good enough for many purposes.

    Anyway, thanks for your excellent remarks.

  1. No trackbacks yet.