Interesting topic for many: what's new in MetaTrader 4 and MQL4 - big changes on the way - page 66

New comment
 
MetaDriver:

What exactly won't happen? Matching, or its automatic consequences?

Be specific, please... ;)

There will be no lessons, that's what. :)
 
MetaDriver:

What exactly won't happen? Matching, or its automatic consequences?

Be specific, please... ;)

Your exaggerated consequences.
 
MetaDriver:

What exactly isn't going to happen?

There won't be anything. One big metatrader. And silence.)
 
MetaDriver:

You have no idea how much you've got. The mass introduction of Matching on MT5-platforms in some sense may become a market "bomb", because theoretically it could lead to an "anti-market revolution" in the Forex market in the very near future. Maybe the term "revolution" is an exaggeration, maybe not, because any trader will be able to market maker (influence prices). With the mass spread of native aggregators covering significant segments of the world market.... the era of (well, almost) monopoly power of liquidity providers over currency pricing may (could) be over forever.

Against this background, the "epochal" question arises: Are traders ready for the "new era"? What regular tools do the "general trader masses" have for testing, optimising and debugging spreading algorithms?

None.

There is no tick history and no debugging in the tester. The format of the quote base does not leave a chance to use it for testing and optimizing HFT strategies using limit orders (which all spreading algorithms are).

I agree with that. Just a counter-argument: The current format of quotes is as dumb for breakout strategies as it is for reverse ones, but you cannot fix it by such a simple method as this. You can cure at least one class of strategies, while in the upcoming situation it takes a "dramatic shape" (see above). And the other strategies will not suffer! If you see it, give me an example of a class of strategies for which modifying the spread in the proposed way will make the testing/optimization less realistic.

In fact the tester is still tickwise, so it is only a question of the format of history. And also the possibility of using "non-standard quotes" if necessary.
MetaDriver:

I'm trying to "look around the bend" a bit further // Everything you wrote is correct.

"Mass market making", precisely because of the triggering of the scenarios described by you, may eventually lead to the loss of the "universal exchanger" position by the dollar. This is a simple consequence of a collapse in spreads on "minors". The foreign exchange market will become more dynamic and efficient. And it is trading systems based on forecasting (rather than on price manipulation) that will benefit. For me, any non-market regulation of exchange rates is fraught with major abuses. It does not matter how noble the goals are declared - there is always the possibility of monetization of the insider and it is foolish to assume that any legal mechanisms can oppose it.

In short - I am interested in "honest Forex", maybe I personally will not benefit financially from such a reversal (or maybe I will). But if I lose, at least I will know that I lost because I developed a dumb algorithm, and not because I was "cheated".

No comment for now. I'll think about it some more. I haven't seen a single profitable strategy that trades a constant lot purely on stops. Not a single one. Theoretically it is very understandable. ( To assert that such strategies exist is to assert that there is any trading horizon where H-volatility is consistently greater than 2.0) All trend strategies that I've seen working are either filled using market orders or entering/exiting on pullbacks using limiters (or market puts). For highAsk/lowBid markets the history is not more valuable than LowAsk/HighBid. For them the important information is rather about the spread at all points of the bar OHLC.

Finally comes the understanding that half-measures like HighBid+LowAsk will not be enough to make a tester adequate.

 
Urain:

Finally it is clear that half measures like HighBid+LowAsk will not be enough to make the tester adequate.

If you're drawing such a conclusion from what I've written... then you don't get it either)
 
TheXpert:
If that's what you're inferring from what you wrote... ...then you don't understand either.)

What are you going to do?! He'll come in, say a few words, and that's it, a couple of sleepless nights are guaranteed. )

The post wasn't for me, but I won't sleep either.

 
MetaDriver:

( To argue that these exist is to argue that there are any trading horizons where H-volatility is consistently greater than 2.0 )

well that's a grail of a trend at all. Neither is it consistently less than 2x. There are no such instruments where H-volatility along the entire series is steadily less or more than 2. On separate segments/at separate moments. Know when to trade a trend, when to trade a return. Filter the bazaar))
 
hrenfx:

I needed to improve my tester for a new trade. To understand the code of the old one was more time wasted (I killed several weeks - occasional approaches), than to write a new one.

So, it took me 5 hours (with debugging) to write a new tester from scratch. Its performance (satisfying to me as a starter):

  • Works with M1 HighBid + LowAsk (results are more accurate than in MT5-tester).
  • One symbol.
  • Speed (i7 2700K) about 100,000,000 bars per second (277 FOREX years per second) on test TS - not empty, many things are calculated. Constantly in the market.
  • No MM - no lots.
  • Profit only in pips.
  • Trader has possibility to control the slippage and commission.
  • Optimizer with its own optimization criteria - for each of them it opens its own file (can take many GB) with sorted strings of trades.
  • There are no error checks in the tester - I know all the nuances of my tester, so I don't allow it.
  • TS is written in a slightly abridged MQL4 - all unnecessary things have been removed. But you can use all the power of C++.
  • The tester is written without OOP - I don't know how to do it competently. So it's practically a pure C language.
  • Source code in free C++~ 20Kb.
  • Stops and marketplaces were thrown out (OrderClose was left) - not necessary.
  • Every run (by choice - specify run number) can be visualized and studied in the math package - Equity and Balance changes file is written simply.
  • No genetics.
  • No OpenCL - can't do it.
  • Single-threaded. Loads all cores stupid - multiple optimizers manually run.
  • Console application.
  • TC input parameters, tester settings and optimization ranges are set in file.
  • TC is compiled together with the tester into one EXE file.
  • Before the start there are only three files: EXE, history, settings.
  • The optimizer has an interruption of the run, if the current state of the run does not satisfy the conditions (for example, subsidence is too high).
  • MQL4 script prepares the history for the tester, it was written long ago.
  • No dynamic allocation of memory for the order table - once allocated memory and forgotten.
  • No logs - I do not look at them.
  • No order history - in the same way.
  • There is no idea about indicators and everything to do with them - we do not need them for TS.
  • Prices are integer (long int).

If the same nonsense is implemented in MQL5, we can use Cloud in the matrix optimization mode. Only history has to be sent every time - the built-in compression of such information is required.

Theoretically, the speed of ~ 100 Bb/s (at the test TS) can theoretically be achieved. I wonder what is the performance of MT5-tester on the whole cloud in the same parrots?

100 billion bars per second is a good speed for all sorts of research. If converted to other units, that speed says that a year of one minute of FOREX history is run ~300,000 times per second on one symbol.

Most of the time was spent learning the syntax of the language - just googling. Not a programmer.

I'll tell you right away, it's a huge waste of time to write a universal framework for your own modest needs. Better to explore. If something needs to be taken into account - just finish it.

This is only a core, now you need a cunning toolkit for the optimizer. It will take much more time here - you have to think it over.

Here I am reading all this and it occurs to me that either a person is completely lost in streams of his consciousness or at least half of what he wrote is just a common lie.

A self-taught programmer without deep knowledge of the language wrote a single-threaded tester with the performance of 100 000 000 bars per second for several hours? In contrast: people of the highest level of professionalism spend years to create a competent, high-performance HFT tester, create whole teams to work with it and fill it with strategies, and here one person decided to build a tester on his own and immediately got an order of magnitude higher performance of leading (closed) HFT platforms.

Let's just calculate how much bandwidth memory we need to run 100 000 000 bars per second. Each bar is 4 prices + AskLow HighBid, which results in 6 integer types with 64 bits each (prices are integers (long int)). For 100.000.000 bars per second it would require

64 bits * 6 prices * 100,000,000 bars = 38,400,000,000 bits = 4,800,000,000 bytes = . 4 577 Mbytes per second..


This means that this performance can, fundamentally and purely theoretically, be achieved on DDR2 533 memory modules and higher. At least the declared performance is comparable to the physical limit of modern hardware.

But software time costs impose even more significant constraints. These cannot be ignored. That's why I took a fast 64-bit C compiler Win-Lcc 64 and measured the performance of a direct search of an array of bars without heavy mathematical calculations. Please note: we're talking about direct, i.e. the fastest search. Without environment manipulation and other overheads. Unlike dickfix, I provide full source code of my "strategy tester", so that anyone can compile it and measure the performance in their favorite compiler:

#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <windows.h>
#define  LAPS 10000              //Количество серий
#define  ELEMENTS 10000          //Количество баров в одной серии
#define  INVOKE                  //Определено, если требуется эмулировать
                                //вызов функции

//Представление бара
struct bar
{
        long long Open;
        long long High;
        long long Low;
        long long Close;
        long long AskLow;
        long long BidHigh;
};

int main(void)
{
        struct bar bar_array[ELEMENTS];
        //Общее время выполнения стратегии
        clock_t eleps_time = 0;
        //Общее время выполения
        clock_t total_time = 0;
        //К сожалению заявленный объем памяти (100 000 000 баров) выделить не удалось,
    //поэтому выделяем память порциями, 1000 раз, по 100 000 баров за раз.
        clock_t ttime = clock();
        for(int lap = 0; lap < LAPS; lap++)
        {
                //Заполняем бары случайными числами
                for(int i = 0; i < ELEMENTS; i++)
                {
                        bar_array[i].Open = (long long)rand();
                        bar_array[i].High = (long long)rand();
                        bar_array[i].Low = (long long)rand();
                        bar_array[i].Close = (long long)rand();
                        bar_array[i].AskLow = (long long)rand();
                        bar_array[i].BidHigh = (long long)rand();
                        //if(i < 5)
                        //      printf("%i\n", bar_array[i].High);
                }
                //Эмулируем работу ТС c массивом котировок
                //Рассчитываем время на выполнение этого блока и суммируем его, получая общее время
                //выполнения
                clock_t btime = clock();
                //Наша стратегия будет проверять простое соответствие проверяемого бара настоящему.
                //Настоящий бар, это бар чей high > open, low, close а low < high, open, close
                int signal = 0;

                for(int i = 0; i < ELEMENTS; i++)
                {
                        #ifndef  INVOKE
                        if( bar_array[i].High > bar_array[i].Low &&
                            bar_array[i].High > bar_array[i].Open &&
                                bar_array[i].High > bar_array[i].Close)
                                signal++;
                        #endif
                        #ifdef  INVOKE
                        signal += TradeSystem(&bar_array[i]);
                        #endif
                }
                eleps_time += clock() - btime;
        }
        printf("Bars was worked: %i\n", LAPS*ELEMENTS);
        //Печатаем общее время выполнения
    double timedif = ((double)clock() / (double)CLOCKS_PER_SEC);
    printf("Bars %f seconds\n", timedif);
        //Печатаем время выполнения торговой системы
        double eleps_diff = (double)eleps_time / (double)CLOCKS_PER_SEC;
        printf("The TradeSystem time is %f seconds\n", eleps_diff);
        printf("The Eleps tik is %i tiks\n", eleps_time);
        return 0;
}
//
// Функция торговой системы. Принимает на вход бар,
// обрабатывает его и возвращает целочисленный результат
int TradeSystem(struct bar &cbar)
{
        if( cbar.High > cbar.Low &&
                cbar.High > cbar.Open &&
                cbar.High > cbar.Close)
                                return 1;
        return 0;
}

You can see that this code, depending on the Invoke directive, either goes through the array and performs a simple comparison (a very fast operation) or calls a function that performs the same comparison.

Let's see how much time it takes for this code to search and compare 100 000 000 bars:

We can see that it took 1.28 seconds to go through 100,000,000 bars directly, which is almost a third worse than the advertised performance.

It can be seen that the search of 100 000 000 bars with call of calculation function on each bar took 1.79 seconds, which is more than 1.5 times worse than the declared performance.

All tests were run oni7 870, DDR3 3200 8Gb hardware.

Most of the time was spent on actual data preparation (about 9 seconds). Which at the slightest non-optimality in optimizer design will result in huge overhead. But I didn't take that time into account since we were talking only about the strategy run.

You draw your own conclusions. I hope I have shown by figures that the claimed result, to put it mildly, does not correspond to reality. Even the theoretical performance of the code describing the optimizer does not correspond to the claimed result. And if you implement a real tester that approached the functionality of the claimed one, the performance will drop even lower, since any function call and any more or less useful mathematical calculations will immediately reduce the time of the bare search.

 
Avals:
well that's a grail of a trend at all. Neither is it consistently less than 2x. There are no such instruments to make H-wave consistently less or more than 2 throughout the entire series. In some areas/at some moments. Know when to trade a trend, when to trade a return. Filter the bazaar))

Exactly! But in this case we come to limit trading as the final phase of development of an ideal trading system.

Now think with your brain, if an "ideal" system must trade Limits, then why should a real system trade Marquets or Stops? Out of modesty? ;)

 
MetaDriver:

Exactly! But then we come to limit trading as the final phase in the development of an ideal trading system.

how did you arrive at this?))) For mr systems that are effective on a return market H<2 (H-wave a rough estimate and the average of a very large hospital) it is beneficial to limiters. On trending (H>2) with marques/stops. And why should it be an ideal system to trade with limits? Ideal mr yes. But real instruments are a mix of trending and flat sections of different scale (and we get H=2 on average). So think with your brain that there is more than one ideal system)) And there are even more real ones
1...596061626364656667686970717273...75
New comment