A big part of moving away from MT4 was to establish a proper back-tester implementation that would allow us to simulate trading systems outside of this trading platform (not to say much more efficiently and accurately). We started this quest in 2013 with the full development of a Python tester front-end to interface with the F4 framework (our programming C/C++ framework at Asirikuy) which allowed us to perform tests for systems that could be back-tests accurately using only OHLC information from previous candles. Since these systems were our main trading/testing target, it made sense to implement the most computationally efficient simulation method within the desired constraints. However, as time passed several members and blog readers started to inquire about tick-by-tick simulations and whether I wanted to implement them within our tester. Today I want to share with you my experience with the implementation of tick-by-tick simulations and how this feature has now been fully implemented within the strategy tester available at Asirikuy.
–
–
What is the difference between simple OHLC testing and tick-by-tick testing? The simplest simulation methodology available uses the OHLC information from candles and then executes systems only on candle open; the system has no access to current candle High/low/close information and only sees the open price. If a system is executed only on candle open you don’t need to worry about how price behaves inside the candle since all you want to do is ensure that the system got executed at a known price. The first inaccuracy introduced by OHLC simulations is that we usually only have access to the open data (usually the bid) so we estimate the ask price by adding a predefined and constant spread. Stop-loss and take-profit orders can also be problematic if both orders are triggered inside the same candle (because we couldn’t possibly know which one got triggered first) so the use of SL/TP is only accurate within this simulations if the separation between both is wide enough. This type of simulation is perfectly fine for any system that has wider SL/TP values and which closes trades with profits about 5-10x the spread. If the system fulfills these conditions then you can rest assured that your OHLC simple (extremely fast) simulations will be accurate to a high degree.
However once our SL/TP difference becomes very tight, our exit signals become reliant on very fine-grain information or we want to execute systems within a candle (execute a signal before a candle closes) then we need to have much more accurate testing. The next level of testing – the highest possible resolution in Forex trading – comes from the use of tick-by-tick data in order to simulate a strategy. When using tick-by-tick data we use a tick-data file (instead of a file containing OHLC data) and from this file we build all needed OHLC data (which the system might use to make decisions) and we perform the test as if the system was being traded “live” and received this information tick-by-tick. In a tick-by-tick test your system receives both the historical Bid/Ask and current time information from this file, meaning that you have both realistic historical spreads and realistic entry information. Tick simulations are not perfect and still do not account for execution risk (things such as slippage) but this can be included within the simulations as well (by adding a given slippage to all trades for example).
The advantages of tick-by-tick simulations are obvious, because it’s the simulation technique that best approaches live trading, but the disadvantages are also quite big. Perhaps the largest disadvantage of tick-by-tick simulations is that the amount of data becomes very big. A year of tick data is usually around 1GB in length, meaning that a 7 year test needs about 7GB of data. In MT4 people perform these simulations by using a hack that forces the MT4 platform to load this data as if it was a historical testing file created by MT4 using its tick interpolation algorithm but the greatest disadvantage is that MT4 must load this whole file to RAM for testing. This is slow, limits the length of data than can be used and in general is not the ideal way in which you want to implement tick-by-tick testing. In order to overcome these problems I decided to implement tick testing within the Asirikuy back-tester in a different manner.
–
–
Instead of loading a multi GB file into RAM (which is slow and in practice cannot be done for anything but a few years of data), I decided to use a very fast approach using ANSI C file reading functions that can obtain data from the tick data file in a line-by-line fashion. Instead of loading the whole file the tester simply sets a pointer to the file and then starts to read it line-by-line, giving you the data you want without having to worry about how big the file actually is. To make things even faster all the OHLC data is pre-processed and passed to the tester as well, meaning that this data does not have to be recalculated from the tick-by-tick data (which is computationally expensive) but it’s created and available before the test even begins. The tester then looks at the current tick timestamp to figure out which OHLC data can be passed and changes the indexes accordingly as the timestamp for the latest tick moves above that of the latest OHLC stamp. What you have in the end is a tick-by-tick testing implementation that is far more efficient than what people generally achieve within MT4. The tester takes about 5-10 minutes to go through 1 year of tick-by-tick testing while the same system using the MT4 hack takes at least several hours.
I have also made this implementation to be portfolio-ready, so the new feature also supports simultaneous tick-by-tick testing of several different instruments/systems at the same time. With this we now have an implementation that is many times superior to MT4 in every way, with fast tick-by-tick testing, realistic historical swap rates , realistic historical spreads, etc. There is now no feature available in MT4 testing that we cannot reproduce and beat within the Asirikuy back-tester implementation. This opens up the door to the evaluation of systems using much finer data, which allows us to explore inefficiencies that were previously outside of our reach. Since Oanda has tick data available since 2004 we can now create systems using Oanda tick data that go to the lowest possible resolution. Dukascopy also offers tick data (plus we can also trade on Dukascopy through their JForex API) so we now have two tick data sources available for which systems can be created/tested and traded on the exact same feed.
It is also worth mentioning that this is just an additional feature for our tester, OHLC simple simulations continue to work just like before. This new version of the tester including tick-by-tick testing will be released within the next few weeks. If you would like to learn more about how you can quit using the unprofessional MT4 platform and move to a reliable paid, supported, open-source implementation please consider joining Asirikuy.com, a website filled with educational videos, trading systems, development and a sound, honest and transparent approach towards automated trading in general . I hope you enjoyed this article ! :o)
Hi Daniel,
it´s always amazing how you ALONE beat MT4´s *ss all the way – and they do have a team behind them of at least 6 people that do the coding! But they decide to dictate to their users which is “best for them”, and it´s just amazing how long it took for example just to implement a simple feature like setting a fixed spread (without external tools) in MT4. I think people asked for it for several years. Now that latest move with MT4, yea, right… and MT5 does not even ALLOW you to use your own historic data nor set a spread – MQ decided that that is the best way for the end-user. It´s so unreal what they are dictating there…
You seriously should do some more promotion for your software, I am sure THIS is what people really want, just don´t know about it yet.
Keep up the great work and I am sure Metaquotes will be history soon!!
Hi Hans,
Thanks a lot for your comment and kind words :o) I think it’s really important to recognize that I didn’t get my software to this point by myself, there were several Asirikuy members who contributed very significantly through the process and I am sure that I wouldn’t be at this point if it wasn’t for their community contributions and skills.
That said, I completely agree with your point about Metaquotes, they are completely stubborn and it’s amazing to see how they ignore their end-users in such a direct manner. Metaquotes has practiced a “my way or the highway” philosophy that will only take them down when better competition shows up. I am sure this competition is coming (things like CTrader or ProTrader) so I’m pretty sure their days of glory will be over soon. Hopefully competition makes them “wake up” and start making more rational choices aimed at listening to their end-users.
About my software. I’m sure it will be ideal for those seeking to program strategies but certainly not for those who need to have graphic interfaces for development. However for those seeking a serious testing/trading/programming environment with committed support, open source and a strong community behind it I have no doubt that my software is a very good choice.
Thanks again for your comments :o)
Best Regards,
Daniel
Guys, the main problem with such companies that contributes to changes taking too long is that usually those who coded the software leave and someone else if hired who must learn the code, a daunting task. At some point control is lost, no changes can be made and they just disappear out of sight.
Are you familiar with this?
http://www.tbricks.com/solutions/overview
Real thing or bells n’ whistles?
Daniel
Great stuff and congratulations to all involved. I’m really looking forward to this release.
Pepperstone now offer cTrader and they will be promoting it very soon. I’m planning on switching to cTrader/cAlgo as soon as I can. I’m hoping many brokers will follow Pepperstone and Oanda’s lead.
Regards
Rodney
I am very proud to see you have done this. In regards to the ‘hack’ for mt4 backtesting, I do use Birt’s TDS. It’s the best of what we have for what we need to do. I found out that the backtest can be sped up by using a Ram Cache program (like PrimoCache). Depending on the settings of my EA, I was able to backtest 4-7 years of dukascopy data in 40-90 min. But like you said, not ideal, but [up until now] we didn’t have much of a choice other than to go to a different platform. With a ram cache, you need to have enough cache to fit the entire fxt file for maximum effect. You can split it up into two or more pieces (like 2007-2010, 2010-2014), but that adds to the complexity of having to keep up with all of the datafiles.
BTW, can F4 backtester use multiple processors? Can F4 backtester have multiple instances.
Can F4 backester read the data directly from the dukascopy format, or does the datafile need to be stored in csv format? Can the user define how the csv fields are imported into F4?
I can confirm that true tick data backtesting is superior in many ways when you need to recreate the real-time conditions. The real variable spreads and jumps in prices are the two most important things to simulate here.
BTW, if you are reading the tick data directly from the csv file, you should consider implementing some of the functions that birt did in his csv2fxt conversion script. Like being able to detect fake ticks, eliminating duplicate ticks/data, etc.
Hi Jon,
Thanks for your comment :o) I am glad you like this development. Let me now answer your questions:
1. Our python based back-tester (which we call the NST) is capable of using multiple cores and even multiple computers (through MPICH). You also open as many instances as you want. The tester back-tests strategies coded within our F4 framework.
2. The back-tester reads data from a tick data csv file created using tickstory (program available for free at tickstory.com). This is the easiest manner I found to import the data in an easy manner. Tickstory is free and does all the data processing of Dukascopy data for us.
3. You cannot do this without modifying the tester’s code but since you have access to the full source code you can modify it to receive files in whichever format you desire.
I hope this answers your questions. Thanks again for your comments :o)
Best Regards,
Daniel
Thanks for the answers. There is no way to subscribe to comments or get alert when a reply is made, so I didn’t know you answered so quickly.
– Does the backtester have a ‘visual mode’ so that people can replay their strategies in a graphical format? If so, can we control the speed of this?
– Can CUDA or GPU be used to accelerate the backtesting in anyway?
– btw, how were you calculating your swap rates in the screenshot example you gave? Dukascopy does not have separate fields for swap rate included in the tick files that I know of. Are you calculating the swap synthetically somehow? If so, what is the formula that you [can] use for a USD account balance.
Hi Jon,
Thanks for your reply :o) Let me now answer your questions:
– There is no visual mode in our back-tester. However the F4 framework contains ChartDirector so you can generate any sort of “screenshot” you want from trading using this library.
– No, the back-tester has no GPU capabilities. You cannot use OpenCL with precompiled libraries, this only works with C code that you specifically compile into an OpenCL kernel, which can only be done for very specific code. The F4 framework cannot be compiled into an OpenCL kernel as it needs to use a lot of functionality that is not available within OpenCL compilers.
– Swaps are calculated using historical central bank interest rate differentials and charged once per day (triple on Wednesdays) as it’s done on most Forex brokers. See here for some samples of how swap is calculated. However as I have said before you would have access to the source code so you can change this in whichever way you want (implement a different charging frequency, completely eliminate swaps, etc).
I hope this answers your questions :o) Thanks again for writing,
Best Regards,
Daniel