maybe dom can post the old cl always in live results to dissuade doubters and manage expectations on cl151
Results for the week ending September 12, 2014: BasicTM : 1 win ; 2 losses ; net +135 AlternateTM : 1 win ; 2 losses ; net +5 We had today a rare set of 2 patterns 152 back-to-back … pattern 152 have an overall win% around 52.5%, so having 1 loss + 1 win is not a surprise … but the 1st one (which turned out a loss) had a 90% chance of making at least 1 LL (lower-low) after the entry pullback – and we ended-up in the very unlucky 10% bunch. The second one had only a 75% chance of making a least 1 LL after the entry pullback, here we had a nice outcome to the trade.
I think what you see on RAPACapIntro doesn't have a large enough sample-size to be significative ... there is no doubt pattern 151 has a tough time this year, just opposite of the TR patterns which are doing great, because that's the dominant mode of operation of CL for now. That was also the case in 2012, but this year it is magnified by the volatility shrink which reduces the overall number of trades a lot vs prior years. I decided a few weeks ago to release v06 with only the pattern 151 upper-half in the default (recommended) settings, and of course, we just missed a couple of good wins from that lower half. But the filtered (counter-)performance of 151 lower-half was not the reason I removed it … it was the unfiltered performance which really did bother me (and it still does). Since then, I did partition the lower-half in 3, I have (not in v06) patterns 1511 & 1512 with more appropriate unfiltered performance, and what’s left is really bad unfiltered. But I am not suggesting using those patterns at this time (nor the “old” 151), 2014 is proving very challenging for 151 at large, and I think 1515 (upper-half) is the safest way to trade that setup. Anyway, I think the current DD is very normal (in size & duration). For those looking for lower DD levels per contract, CL302 is the system that I recommend (that system just trades patterns 301, 302 & 152). That system is currently near (or at) its P&L peak (and has been for a while).
Does you system account for volatility increase/decrease?Especially when it rises,do you have any components in your system that account for that?Seem that it doesn`t,considering the bell shape of the curve on RAPA.
The patterns are derived off the pivots ... patterns geometry & relationships are expressed mostly as %, on the pivots side I use price, time & volume to identify pivots: - price requirements are adjusted to the current trend characteristics, this allows for some volatility adjustments - volume requirements change day-time vs overnight (with a pre-open window), but are otherwise static - time requirements are also mostly static, but these time requirements provide a lot of resiliency to sudden spikes of volatility I am not as worried with volatility increases (with 2008, we have a fairly extreme reference) as I am with volatility shrink - 2014 is making a new low in volatility on the reference period (2007 onwards for CL), this is new territory - and it does reduce the trade count a lot.
What do you mean by "Time"?Some interval scale,or a particular data set within the bar?I see your using Volume bars type of chart.
I have some time-based rules in the identification of pivots - for example, no 2 pivots can be in the same 1-minute bar. Another example is, a pivot needs to hold for a certain time (which itself has some flexibility, depending on how much volume is transacted from the pivot candidate). Another example, when a price has been "holding" for long enough, but price hasn't bounced enough to validate the pivot, I can reduce the price requirement a bit (only for pivots at the trend-extreme or pullback extreme)
''Bounced enough;long enough'' is too vague.You still go in circles by overoptimizing and overfitting,as the majotiry do.With the bigger sample it`ll be even worse.TThe curve goes alwayas gaussian,or you`ll have to constantly interfere with it.
LoL ... sorry I won't disclose more than that on a public forum ... I haven't touched the Pivots subsystem in 3 years, it is certainly not over-optimized - if anything, it would rather be under-optimized.