Diagonal Lines for EA: Can "Channels" Be Quantified? Why This Idea Failed!
This time, we tried to automate and verify the effectiveness of diagonal channels – those trendlines you often draw on charts – and the results were a
A beginner-friendly summary of the verification: “Diagonal Lines for EA: Can “Channels” Be Quantified? Why This Idea Failed!”.
This time, we tried to automate and verify the effectiveness of diagonal channels – those trendlines you often draw on charts – and the results were a clear “no go.”
What’s the idea?
In our journey to verify the components of a popular discretionary trading approach (let’s call it the “Yosuga style”), we’ve been tackling its core elements one by one. Previously, we had great success quantifying horizontal support and resistance levels (which we discussed in Research 73). These levels proved robust and profitable in our automated tests. Now, it was time to turn our attention to the other major line element in this style: diagonal channels. The goal was simple: could we take the concept of drawing a channel between two swing points, score how price reacts to those lines (touches, bounces), and use that information to generate profitable trades? We wanted to see if these diagonal lines, often used by manual traders, could hold up under rigorous automated testing.
How I tested it
To put diagonal channels to the test, I developed a custom script called channel_lines. This tool was designed to automatically identify channels by looking for significant “swing points” (think of them as peaks and troughs on the chart). Once a channel was identified, the script would then score how price interacted with its boundaries – did it touch? Did it bounce?
Crucially, this system was built with “no-lookahead verification.” This means the script never peeked into future data, just like a real-time trading system. We then subjected it to “forward testing,” which is like giving your trading strategy a series of pop quizzes on data it’s never seen before. It’s a much tougher, more realistic test than just seeing how it performed on historical data it might have been optimized for (that’s called “in-sample” testing, and it can be misleading).
We evaluated performance using a key metric: Profit Factor (PF). This is simply your gross profit divided by your gross loss. A PF greater than 1 means your strategy is profitable overall. We also looked at the percentage profit and, crucially, how consistently profitable the strategy was across multiple forward test periods.
What happened?
In short? The diagonal channels didn’t cut it.
Let’s put it into perspective. Our previous success with horizontal levels (specifically, a strong level score of level≥20) yielded a very respectable +42.2% profit and was profitable in 5 out of 6 forward testing periods. This was a solid, reproducible result.
Now, for the diagonal channels:
- Channel score
channel≥10: This produced a -6.8% loss and was profitable in only 1 out of 6 forward testing periods. Ouch! This was a clear failure. - Channel score
channel≥20: Trying to be more selective didn’t help much. This version showed a tiny +0.3% profit and was profitable in 2 out of 6 periods. But here’s the kicker: it only made 54 trades across all those periods. In other words, it was barely trading at all – practically inactive. A strategy that rarely trades and barely makes money isn’t very useful. What about trying to combine them? We thought, “Maybe diagonal channels can complement horizontal levels!” So, we tested a strategy that would take a trade if either a strong horizontal level or a strong diagonal channel signal was present (level OR channel). The result? This combined strategy made +47.4% profit, which sounds good, but it was only profitable in 4 out of 6 forward testing periods. Think about it: our horizontal levels alone gave us 5 out of 6 profitable periods. By adding the diagonal channels, we actually degraded the consistency of our winning strategy! It’s like adding a slightly rotten ingredient to an otherwise delicious recipe – it just brings the whole dish down. The data clearly showed that the low-quality entries generated by the diagonal channels were eroding the consistency of the robust horizontal level entries. Interestingly, the diagonal channel strategy looked somewhat promising on its in-sample data (the historical data it was initially developed on), with Profit Factors of 1.49 and 2.20. But this proved to be a “selective mirage” – it looked good in the controlled environment, but completely fell apart when exposed to fresh, unseen data in forward testing. This is a classic trap in algorithmic trading and highlights why forward testing is so critical!
What I learned
The conclusion is unambiguous: diagonal channels, as quantified and tested here, are rejected for automated trading. They simply weren’t robust in forward testing, and trying to combine them with our successful horizontal levels actually made things worse.
This outcome is quite telling, and it aligns perfectly with something the “Yosuga style” teaching material itself states: that “channels are generally weaker than horizontal lines.” Our data-driven verification has now empirically backed up this hierarchical view, confirming that horizontal levels are indeed the more potent element. We’ll stick with our robust horizontal levels (from Research 73) for now.
This entire exercise underscores the immense value of our verification framework. It’s not about blindly accepting that “all discretionary trading elements work.” Instead, it’s about having a system that can factually differentiate between what works (like robust horizontal levels) and what doesn’t (like these diagonal channels). This ability to identify effective components based on hard data makes our hypothesis testing highly reliable.
And don’t worry, the channels.py code isn’t going into the digital trash bin! It’s now a permanent asset in our toolkit, ready to be revisited for other potential uses or future re-verification if new ideas arise. You never know when a piece of code might find a new purpose!
How this connects
This verification builds on earlier ones (what failed before and what I tried this time, comparisons between approaches).