Algo-brainstorm

Well, that's kind of hard to discuss without any price or time axis labeling, or whatever the blue line is which seems to be a moving average.

I didn't put scales for a reason, it is important for me to understand the principle of how best to implement, not to implement a particular pattern. The blue line is a moving average, but it can also be just a level. Specifically here we see that there was a false breakdown down after a consolidation , then a small consolidation and the price breaks up, then again consolidation, pullback and upward price movement. My task is to implement this algorithm.

I would go with a PriceGrid, I'm not sure why you think it would not help.

QUOTE:
I would go with a PriceGrid, I'm not sure why you think it would not help.

Because the consolidation phase can be 4 bars but can be 10 or more bars, as well as pullback can be right up to the moving average, or it can not reach the moving avg as here. Such differences on a small timeframe will give a lot of garbage trades. PriceGrid doesn't understand what is critical to the setup and what isn't, it looks at the picture overall. It's impossible to make it only look at the price scale, but not at the time scale.

Maybe a custom Chart Pattern for the Chart Pattern extension would be a better fit. I’ll see if I can come up with something there.

QUOTE:
we want to trade this pattern,... to enter after a pullback

I see a 3-state pattern here. A consolidation [state 1], followed by a significant pullback [state 2], followed by a stop Buy entry [state 3]. I'm not sure how high you want to set the stop Buy to avoid false entries.

But for a 3-state pattern, why can't you do this is C#? The first and second state can be detected* in the Initialize{block} and the third state has to be left for the Execute{block}.

*By "detected", I mean queued up in Initialize so it can be later processed (dequeued) in Execute for analysis. Understand, just because the activity passes the first two states doesn't mean it's time to place a stop Buy in Execute. You may want to see if a few other "plants" (i.e. indicators) line up before pulling the trigger in Execute.

.NET has a FIFO queuing datatype you can use to collect pattern candidates that successfully pass states 1 and 2 that are queued in Initialize. Execute can then dequeue each candidate when it gets to its appropriate bar. There's a Peek method to check if the next element leaving the FIFO queue would be the bar Execute is currently on before dequeuing it. This approach does require a competent C# programmer that can manage elements on the FIFO queue, but it's not that hard. I usually reference a "struct" object of pattern-merit attributes on each queue element as well so I know something about that particular pattern opportunity; not all confirmed patterns have the same merits.

The PeakTroughCalculator works on a similar principle. It populates its doubly-linked list of PeakTroughs in Initialize, then you can examine that list (along with its PeakTrough attributes) in Execute to place your trades.

---
It may take several stop Buy attempts before the stop Buy fills; therefore, dequeuing needs to be done by either the Position-open code (after there's a confirmed fill), or in the Position-closed code after the stop Buy opportunity ages out (never fills).

QUOTE:
Maybe a custom Chart Pattern for the Chart Pattern extension would be a better fit. I’ll see if I can come up with something there.

Any new thoughts on this?

I really haven't found a better tool than PriceGrid for this, but it's not enough. I'll try to show.

From a technical analysis and human point of view these 2 pictures are almost the same, but from PriceGrid point of view they are different. In the current implementation I can't force PG to take into account the character of price change vertically and weaker to take into account similarity of change horizontally. Describing this simply in code is an inordinate amount of effort, so I still haven't found the perfect solution.

QUOTE:
from PriceGrid point of view they are different.

I totally agree. I wouldn't use a price grid for "generic" pattern matching. At least not in the "temporal" domain. (Perhaps you could in the frequency domain, but that's a topic for a signal processing forum.)

QUOTE:
Describing this simply in code is an inordinate amount of effort,...

No, no, it's not. You need to build a finite state machine in C#. For pattern searching in Initialize, define a FOR loop to increment through all the bars. Inside that FOR loop place a SWITCH statement where each CASE of the SWITCH statement represents a different state in your state machine. Add a state pointer that you can increment from one state (or CASE statement) to the next. As with any state machine, sometime you may need to backup a state. And if your pattern search fails along the way, then you need to reset you state pointer to the first state and begin a fresh pattern search.

Each CASE statement tests the criteria for that particular state. If it's met, you increment you state pointer to the next state (or CASE statement). If it fails, you either backup one state, or reset the state pointer to the beginning for a fresh pattern search. I find each CASE statement to have about 5-7 lines of code for evaluating that state and adjusting the state pointer accordingly.

This is all done in the Initialize{block} until you get to the final state, which is a Stop Buy order that must be done in the Execute{block}. So when your finite state machine reaches all but the final state, you queue that pattern match into your FIFO queue in Initialize. Execute can then peek (and eventually remove) those queued pattern matches when it reaches the bar in question to place the Stop Buy order.

This doesn't take much code. Just follow my discussion in Post #6. Managing the FIFO queue is a little tricky in Execute because you don't know if the Stop order will fill or not. So don't dequeue the pattern candidate until the Stop order ages out for 3 bars or so. And if it does fill, then you can dequeue it immediately in the Execute open-position sell code.

This isn't hard, but it does require an experienced programmer. I typically add a "struct" PatternAttributes instance to the FIFO queue element because some pattern matches have better merits than others, and Execute may want to evaluate them when formulating its Stop Buy price.

---
Off topic, but for pattern trading, I would pick a pattern with at least 4 or more states. Although the short patterns are more frequent, they rarely lead to winning trades (So what's the point?). In contrast, the longer patterns do reveal winners, but those patterns are infrequent.

superticker, thank you for the detailed response! Since there are no alternatives, I'll just do it this way.

QUOTE:
Off topic, but for pattern trading, I would pick a pattern with at least 4 or more states. Although the short patterns are more frequent, they rarely lead to winning trades (So what's the point?). In contrast, the longer patterns do reveal winners, but those patterns are infrequent.

I was just giving an example. I don't use patterns in pure form, only in combination with other criteria, there are actually a lot of them in my strategy. Specifically this strategy is scalping on 1 and 5 minutes, and here short setups give very good profit.

QUOTE:
I don't use patterns in pure form, only in combination with other criteria,...

That's the right way to do it. A 4-state + 1-stop Buy (5-states total) pattern alone will only give you about a 60% win rate, which is poor. But if you combine that with an indicator or two in Execute, you may achieve a 70% win rate, which is likely profitable.

In addition, the published patterns are looking at price action alone. That's not the best way. Probably developing patterns that model something like money-flow action (which takes both price and volume together) would be much better. But that pattern behavior would be somewhat different.

Finally, a pattern search on the 1- and 5-minute scales might be the wrong approach here. I would try using the WL Candlestick extension instead for the smaller scales (where you're really modeling trader psychology, not price action).
https://www.wealth-lab.com/extension/detail/Candlesticks

It's nice to meet another oops programmer. Happy coding and computing to you.