Trading in the FX market using mechanical trading strategies

Through the evolution of Asirikuy trading systems we have gone from very primitive implementations (much more hobby than production quality) to functionally decomposed systems with professional coding standards with adequate error handling and a ton of flexibility. In the beginning coding new systems and getting to know why something had failed was a nightmare while right now we have a source which we can easily use to create new systems with a very efficient use of functions amongst all the different strategies implemented within Asirikuy. However – seeking to improve this framework – it’s our idea to move in the medium term from our current F3 implementations to a much more advanced F4 framework.

In the beginning my intentions with F4 were geared towards simplification. Right now we have a ton of functions in our Asirikuy framework which are coded individually on each system and this makes general updates difficult as each EA needs to be modified and sometimes specific functions have to be tailored for systems which have slight variants of the general functions. Adding and modifying some functions isn’t trivial as the framework can get quite different when moving from a simple system like Teyacanani to a much more complicated one – from a coding point of view – like Watukushay No.5. Systems that need to handle multiple positions and systems that trade using pending limit/stop orders currently have different function implementations which makes updating harder.

–

-

Originally I simply wanted to take all these functions and put them within comprehensive libraries that all systems could call. For example we could have a single file which includes all relevant order opening functions such that a system that wants to open a trade simply calls the “open buy” function with a certain set of parameters. For some functions this is trivial (like for order opening functions) but for others it becomes more complex. This also demands that each system should have its own library for its “private” calculations (like indicators and other similar stuff) something which is also worth doing since we would have a much more organized coding structure.

However an Asirikuy member sent me an email about taking F4 a step further so that we could make the code not only more organized but platform independent. This Asirikuy member had the great idea of building a universal XML structure which can then be used to build the systems using parsers towards any language we would like to use. This means that by building the F4 framework for our systems on MT4 we would be building the framework simultaneously for Mt5, C++, Pascal and any other language for which we build a proper parser. I believe this idea is brilliant since it gives us the option to simultaneously move onto MT5 and get platform independence from Metatrader as a whole. This opens up the door towards the parsing of our systems to the JForex platform in a very easy fashion.

Of course, the amount of things that we need to do is nothing short of gargantuan as we first need to get an organized XML definition and a code structure that will encompass what all of our systems do. The idea with this is to enable very easy logic and functional modifications that will allow Asirikuy members not only to build systems in a much easier way but to have them multi-platform-ready. This of course is a lot of work for a single Asirikuy programmer and therefore we will be putting together a team which will work on this effort to make this Asirikuy “system building tool” a reality. I will certainly do as much as I can to make this a reality and certainly the effort will pay off greatly in the form of a very versatile way of building systems that will be one order of magnitude superior to our current “single language” approach. If the future we want to build systems for a new language or platform then we simply need to get a parser, how cool is that?

Certainly it shows – yet again – that Asirikuy is a great community because of the great members it has. On my own I probably would have never thought of about half of the ideas which have been contributed by Asirikuy members, each new member who “does his or her homework” and contributes with an original idea or development project helps make the understanding of the whole community grow exponentially. I never thought Asirikuy would becomes something so great so quickly but it has certainly done so thanks to the great community which has grown around this website. If you are an Asirikuy member looking forward to work on this then keep an eye on the programming forum as we will be starting some threads to decide who will work on this project and what our goals will be soon.

So this is yet another on the great list of endeavors we are embarking ourselves on in Asirikuy. This project to build the F4 framework will probably take at least 6 months but I have no doubts about its completion because I know the level of commitment I and other Asirikuy members have to our systems and their progress. If you would like to learn more about my work in automated trading then 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)

I hope however that this will not impact too badly the performance of the systems as Generics and high-level frameworks usually tend to add overhead operations and it sometimes translates into performance degradation.

Thank you for your comment :o) Well the idea is to have zero performance degradation as the code is generated in each specific language so we want to have more flexibility without having added problems. Of course the F3 framework will continue to be improved as we migrate so it will continue to be Asirikuy’s stable branch until we make sure we have something better. Thanks again for posting!

I didn’t grasp that you wanted to use an ontology in order to generate platform-specific code. I thought you meant using some neutral data structure like xml that can be used through various platforms.

If you are talking about generics-driven code-generation, then it is even more amazing than what I initially thought :)

At the risk of being the odd one out (which to me is no surprise) i would only like to say the following.
I have been in software for >15y (finance for >20), designed, developed and sold the foundation of a generic asset mgt system and decided 11y ago that there were two things any modern (oo based) system should get rid of.
1. The outdated and over the consumption-date relational databases (does it make sense to work with objects and then flatten them to persist them??). Object databases are more natural, logical and faster as well.
2. No XML. The system we (my company, 12 academics working on the system) were putting together had a C++ back-end (Unix) and a client that was dynamically put together using xml that was produced and supplied to the client by the server. We got it to work but we had to use a lot of aspirin. If and when xml is used it should actually be in a >2 dimensional (read proper object) environment, but in 95% of the applications i have seen so far xml is used in 2 dimensions. An utter and complete waste, better to use normal simple and readable property files.

Undoubtedly this post will cause some raised eyebrows and maybe even some ‘religious’ reactions from xml ‘fanatics’, which is all fine with me ;-)

I still (will) appreciate the site, the forum and the work and insight of Daniel and other members. I have the nothing but the utmost respect for them and the accomplishments.
I just felt i needed to voice my opinion on the proposed use of xml for the creation of the foundation of the new Asisikuy environment, that’s all. To me it is a wrong choice that will cause a lot of headaches in the future. However, for the sake of Asirikuy i hope i’m completely wrong on this one.

Thanks a lot for your comment :o) Well, we still haven’t implemented (or started implementing) anything yet as we first intend to discuss this within the forum to come up with the best possible solution. Asirikuy is a rational community so we will try to implement whichever choice is in our best interest. Of course we will greatly value your opinion and insights when we start to discuss this on the forum! (probably the real idea is a little bit more complex than what was exposed on this blog post so it will be great to see your opinion on the true “big picture” once we start discussing it on Asirikuy) Thanks again for commenting!