Discussing the article: "Developing a Replay System — Market simulation (Part 21): FOREX (II)"

 

Check out the new article: Developing a Replay System — Market simulation (Part 21): FOREX (II).

We will continue to build a system for working in the FOREX market. In order to solve this problem, we must first declare the loading of ticks before loading the previous bars. This solves the problem, but at the same time forces the user to follow some structure in the configuration file, which, personally, does not make much sense to me. The reason is that by designing a program that is responsible for analyzing and executing what is in the configuration file, we can allow the user to declare the elements he needs in any order.

In the previous article, "Developing a Replay System — Market simulation (Part 20): FOREX (I), we started to assemble, or rather, to adapt the replay/simulation system. This is done to allow the use of market data, for example, FOREX, in order to at least be able to make a replay for this market.

To develop this potential, it was necessary to make a number of changes and adjustments to the system, but in this article we are considering not only the forex market. It can be seen that we have been able to cover a wide range of possible market types, as we can now not only see the last traded price, but also use a BID-based display system, which is quite common among some specific types of assets or markets.

But that's not all. We have also implemented a way to prevent the replay/simulation system from getting "locked" when tick data shows that there were no transactions for an asset for a certain period. The system was in timed mode and was released after a certain time to be used again. We currently do not encounter such problems, although new challenges and problems still remain, awaiting solution and thus further improvement of our replay/simulation system.

Author: Daniel Jose