Buttonwood_v4: organizing the filters and getting to phase 2
We've spent some time testing different market weather filters, and have come up with some promising candidates. It's now time to move the system forward past the first phase. If you remember from the "conceptual overview" post I made towards the beginning of this thread, I mentioned three components:
1) Determine the market's weather. Are we in a day that is trending or pulling back? ("Weather" component)
2) If we are in a trending day, trade. If not, stay clear. ("Entry/Exit" component)
3) Monitor various filters, etc, to help us fine tune and tweak the entries so they occur appropriately. ("Filters" component)
We have now gotten to the point where we have fleshed out a workable solution for the weather component, and also a poentially workable solution for the entry/exit component. That's not to say we're done with them, but we've made some progress. What I've done in version 4 is merged our two weather forecasting algorithms so that the system trades if either the Progressed-to-Natal function triggers, or the Spherical-Conjunctions function triggers. Here's what that looks like in the system report:
- System Report for Buttonwood_v4
- v4_system_report.png (36.85 KiB) Viewed 30788 times
- Equity Curve for Buttonwood_v4
- v4_equity_curve.png (35.9 KiB) Viewed 30788 times
Let's take a moment and consider what we've come up with this far, in terms of pros and cons:
Pros:
1) Our system has a nice, upward sloping equity curve without too much adverse movement.
2) We've got over 2500 trades. That's a LOT of trades. From a degrees-of-freedom/curve-fitting perspective, the more trades you've got, the better off you are. It's very easy to build a good looking system if there are only 10 trades that go into it, but it's much harder to build one with thousands.
3) Our drawdown-to-profits ratio is very low. If you rephrase the numbers in terms of dollars earned per dollars risked, you find that we're cranking out roughly twice our drawdown amount per year in profits.
Cons:
1) 42% accuracy is a little low. Of course, this is trend following, so this might just be part of how this system operates.
2) Our average trade is too low.
That last point about the average trade is really the issue right now. Although we aren't really going to suffer one tick of slippage every single trade, as we'll be using limit orders to enter (why would we voluntarily agree to pay the spread?), when building a system, we
must assume that we'll be using market orders. Paying a tick on the way in, and a tick on the way out costs $25 per trade, multiplied by 2662 trades, results in a slippage cost of $66,550. This is why daytrading systems are so hard to build - all the profits go to pay slippage and commissions. If we were building a daily system, we'd have an average trade value of around $200-$300 or so, and a tick here or there really wouldn't matter at all. But in this case, a tick here or there is huge - it's enough to wipe out the edge we currently have. This is why I've been focusing on the average trade value so much in the past few posts, and why it's such a critical thing to keep in mind when building intraday systems.
So right now we've got a theoretical edge, but in practical terms are only breaking even. Not losing money over the long haul, but not really making it either. Framing that in a positive way, it means we're ahead of roughly 90% of market participants, which gives you something to think about.
Our goal then is to figure out how to bump that average trade value up. Every additional dollar we make at this point goes to our profit pile, as we have already got to the point of paying the bills. So we need to figure out how to place better trades, or find a way to avoid placing losing ones as frequently as we currently are. Now that we're past phase 1 (market weather), we can look to all aspects of our system for improvements. Here's a quick list to start:
1) Build another market weather function, and do a two-out-of-three filter system, rather than an either-or like we have now.
2) Tighten up our threshold levels to restrict trading to only the most volatile days.
3) Look for better signals than our 8/34 averages are giving us.
4) Look for day/time/pattern/etc filters, along the lines of the big list that orionsbelt posted earlier.
As promised, I've added a function to allow us to explore point 4 in that list. In the script, you'll see it written like this:
Code: Select all
#other filters -----------------------------------------------
other_filters = Buttonwood_AdditionalFilters();
If you want to mess around with ideas, you just open up the Buttonwood_AdditionalFilters function, and can experiment with writing filters. Return a "true" value if it's OK to trade, and a "false" value if it's not. You don't have to change anything in the main script to test your ideas, and there's no way to break this, as you can just wipe out your work and start over, so don't be afraid of that function - it's quite resistant to scripting errors.
Right now I'm not doing anything there, and just have the function set to return "true" no matter what. If you're a beginner with QScript, this is the place to look for improvements, as the scripting will be the easiest. For example, you can do something like:
Code: Select all
if (time < 1400) return true;
else return false;
Assuming your computer is in Eastern Time, that's going to chop off all trading after 2pm, which is starting to get too close to the close of the day to be profitable. That one change is going to bump the average trade up to almost $30, so you can see how a few of these can be used to start helping the system claw its way into the profitable-in-real-life category. As a quick aside, the way to write the above code so it works for everyone in any time zone would be like this:
Code: Select all
if (time < (1400 - timezone*100))
return true;
else return false;
So in this case I'm subtracting the user's time zone (multiplied by 100, since that keyword only returns a single number) from 1400, which will give the correct number no matter what time zone the user is running their charts in. Just a subtlety which you don't have to worry about if you don't want to, since it's easy to fix later on if you find something good.
Anyway, I'm trying to give everyone access to improving this system, according to their own scripting skills. So beginners, check out the Buttonwood_AdditionalFilters. If you're a beginner and feel like stepping up your game, you can look at Buttonwood_Signals as well, which is the same sort of thing, but slightly more involved. In that case, return a -1 to go short, and a +1 to go long. I think there are some big gains to be made in both of those functions. Finally, if you're very comfortable at scripting, or just want to mess with your head
, go fool around with the weather functions, which are the most complicated.
All for now. We've actually come to an important milestone with where this is at, so now it's time to start tweaking and finessing and see if we can get this trade-able.
Regards,
Earik