New Algorithmic Trading Timeframes: Just shift it!

During the past few months I have been thinking about an important problem in algorithmic trading related to entries and volume. When you create systems that trade using a given OHLC timeframe – such as 1D, 1H, 30M, etc – you suddenly start to accumulate trading volume at a given fixed point in time and you become limited in the amount of volume you can trade without being noticed. You become predictable due to the way in which you’re entering your trades and your ability to generate new systems also becomes limited because your entry times and past reference points are constrained by your timeframe selection. On today’s post I am going to reveal my final solution to the above problem which completely eliminates most issues without increasing the computational cost of trading simulations.

Selection_713

Selection_714

Suppose you decide to build systems using OHLC data on the 1H timeframe. You cannot go any lower because you don’t want the additional computational cost of dealing with the 15M or the 30M timeframe. Soon you realize that you have several problems, your entries are constrained to just 24 possible points per day and the volume you can trade is limited to the volume available at the start of each trading hour. Your ability to find systems is also limited by whatever you are able to discover by referencing the 1H chart and you fully depend on inefficiencies being reflected within the OHLC of the timeframe you have chosen. It eventually becomes clear that you’ve boxed yourself in and you have no exit. Your strategies don’t work on the higher timeframes (4H, 1D, 1W, etc) and you cannot go lower because of computational constraints. What to do?

The answer is much simpler than it seems. You can only run simulations on data that is compressed such that each chunk represents a 1H trading period but there is no rule about where those 1H chunks start and end. The way to completely free yourself from the constraints imposed by using the traditional 1H timeframe is simply to generate more timeframes that are still 1H chunks but shifted by some value. That shift can be whatever highest resolution data you have, so for example if you have 1M data available you can create 59 new timeframes that are simply 1H timeframes that have been shifted from minutes 1 to 59 built from the 1M timeframe. Suddenly you don’t have a single 1H timeframe but you actually have 60 and suddenly you’re not restricted to 24 entry points but you have 1440. At this point you have access to the entire liquidity range of the market and you didn’t even increase your simulation costs by one bit as you’re still running your simulations on 1H chunks.

Selection_716

The above obviously applies to every timeframe you can think of that is above your highest resolution data. Think about the first two charts shown above for the USDJPY which are two daily timeframes. The first is not shifted (traditional 1D timeframe) and the second is shifted by 8 hours. Suddenly there is access within the daily timeframe simulation costs to a lot of the diversity that is present within the 1H timeframe. This is indeed a way to access higher resolution entries without having to increase simulation costs. In the past I have mentioned how finding machine learning systems that were profitable within the 1D was really difficult for non-EUR/USD symbols because entries where constrained to unfavorable points — with this development this is no longer an issue.

Differences in the statistical properties of the generated series suggest that the inefficiencies found on one may be different than those found on another. For the above USDJPY daily series (0 and shifted by 8 hours) we can already see some relevant differences in the distribution of returns. The mean, standard deviation, skewness and kurtosis of the two return series are different and sometimes these differences are surprisingly large (in the 20-30% range). The fact that the references to past data are different (obviously the entire OHLC changes) plus the fact that entries now happen at completely different points make the use of shifted timeframes invaluable for the finding of potentially new trading systems.

Selection_717

Obviously things like the above are much harder to implement when using trading platforms that do not allow you to change the way in which you perform back-testing and live trading. For example platforms like MT4 where the base timeframe choices are limited by what the program has to offer make it very hard for a trader to implement something akin to what is suggested within this article. However using a back-testing and live trading engine where you can make any coding modifications you want it is relatively easy to introduce these changes and allow you to live trade in this manner. Certainly there are some additional computational costs as custom data arrays have to be built when live trading (as brokers do not provide you with OHLC 1H series shifted by 2 minutes for example) but it can certainly be done much more easily.

Certainly the next step is to implement shifted timeframes within our pKantu GPU based price action and machine learning system mining efforts in order to generate systems that provide a new avenue for diversification within our community. If you would like to learn more about back-testing and how you too can perform simulations with a back-testing engine where you have access to the entire source code please consider joining Asirikuy.com, a website filled with educational videos, trading systems, development and a sound, honest and transparent approach towards automated trading.

Print Friendly, PDF & Email
You can leave a response, or trackback from your own site.

One Response to “New Algorithmic Trading Timeframes: Just shift it!”

  1. James says:

    Nice article Daniel!

    Another benefit of using shifted timeframes is that the processing power required when live trading is no longer concentrated at specific times.

    I look forward to this being implemented in F4 :)

Leave a Reply


Fatal error: Call to undefined function mcsp_html() in /home1/danielfp/public_html/mechanicalforex/wp-content/themes/modern-style/comments.php on line 71