The ProRealAlgos proved algo development process

Let's talk trading ideas. Let's talk about your sources of trading ideas and let me share with you our own favourite sources of ideas. I will also share with you 3 interesting ideas from our own backlog, that we haven't had the time to test yet. Enjoy.

• prorealcode.com
• quantifiedstrategies.com
• Books from the video
• Ideas spreadsheet (make a copy)
• Join the community chat

Need to learn the essentials of ProRealTime and the basic coding language? Here's a video covering the must-haves. If you already know the basics of ProRealTime and have some basic understanding of programming, you can skip this video.

I'm going to show you the interface of ProRealTime and the features you will use when coding algos. This is not a course on programming, but I'll quickly show you the basics of what you need to know.

We get into how to code and evaluate trading ideas in ProRealTime by coding the three ideas we covered two videos back. Carl will show you the 4 metrics that ProRealAlgos use to evaluate trading ideas quickly and effectively.

• Trading idea #1

In this video we start adding some filters, features and finess to the trading idea that we coded in the last video, to make it even better. Slowly turning it into a viable system that will create a passive income stream for you for years. So grab a coffee and join me.

• Full code including new filters and features

The Stochastic MACD indicator is a combination of the stochastic oscillator and the regular Moving Average Convergence / Divergence. Let me show you how to use it with ProRealTime to find the best possible entries and exits.

• SMACD + Divergence + Backtester .itf files

When building a trading strategy the possibilities are limitless. You can add hundreds of different indicators, filters, oscillators, codes and features, but I have found that new developers find it hard to know where to start, just because there are so MANY possibilities.

So I am going to help you get started by guiding you with some simple filters on trading hours, days and seasons.

• Full code of the DAX40 strategy

Chapter 2D is about trading hours, days and months. Here is what a real one looks like when you can check the answer.

We generated two price series. One has a genuine effect planted in it: the first four hours of each day carry real upward drift and the rest of the day is noise. The other is noise all the way through. The same simple rule, long inside a four hour window and flat outside it, was run on both.

Series with the planted effect: profit factor 3.44 over 104 trades. Series without it: profit factor 1.10 over the same 104 trades.

The gap is the whole point. A time filter that is picking up something real keeps working when you move the window a little. A time filter fitted to noise falls apart the moment you do, and on a single backtest the two look alike.

In this learning video Carl goes through several methods to test and evaluate your algos, and their different advantages and disadvantages. There are no perfect ways, but there are definitely methods to avoid.

Walk-forward testing is the antidote you need to avoid overly optimizing your backtest and to make the best use of the available historic data. It is widely recognized as the de facto method for backtesting and optimization.

• Full code (.itf) of the Walk-Forward example

A strategy with seven adjustable numbers was run on a price series with no edge in it whatsoever. Not a weak edge. None. The series is a random walk and we know that because we generated it.

Tuning the seven numbers produced a rising equity curve over about a hundred trades. Then nothing was changed except the random seed, which produces a different stretch of the same edgeless process:

Seed 7, profit factor 1.09. Seed 11, 0.83. Seed 23, 1.34. Seed 44, 0.71. Seed 91, 1.24.

A profit factor of 1.34 on a hundred trades looks like a finding. It is nothing at all. That spread, on data guaranteed to contain no edge, is what overfitting produces, and it is the number your own backtest is competing with.

Five price series were generated. One has a specific rule planted in it: after three consecutive down closes, the next bar carries real upward drift. The others do not.

The matching strategy, buy after three red bars and hold five bars, was run on each, averaged over six seeds so that one lucky run could not decide it:

Planted edge, profit factor 1.84. Session effect, 1.55. Mean reverting, 1.10. Trending, 0.96. Pure noise, 0.86.

The planted one does stand out, over six runs. On any single run it does not: 1.84 and 1.10 overlap comfortably in one sample. That is the finding worth carrying around. One backtest cannot separate a real edge from a lucky one, and no amount of staring at the equity curve changes that.

A system you licensed is in drawdown. You get what you would really have: the record you were shown before you bought it, and the record since. Keep it running, or stop it?

One scenario in three keeps its edge the whole way. One loses it the day you go live. One never had an edge and the backtest was a good run on noise. Because the bars are generated the right answer is a fact rather than an argument, which is the only reason a drill like this can exist at all.

Scoring well above chance is hard, and that is the finding, not a flaw. When you cannot reliably tell a dead system from an unlucky one, what saves you is position size and a rule written before you started.

Open the drill

Decide this while nothing is at stake, because you will not decide it well halfway down. A usable rule names a number and a horizon, not a feeling.

Three of the pieces are already in the ProRealAlgos support answers: run the systems together, because one is in drawdown while another is making money; check in weekly or monthly rather than daily; and remember that stopping an algo does not close its open positions.

Every page of the reference ends with a section called common errors and gotchas. There are 1,168 of them across 301 instructions, each one a specific way that correct looking code does the wrong thing.

They are also the shortest way to check code you did not write. An AI will happily hand you ADX[14](close), which looks reasonable and is a syntax error in ProRealTime, and the ADX page says so in one line.

Open the reference