Discussion of article "Developing a cross-platform grider EA (part III): Correction-based grid with martingale" - page 5

New comment
 
Ben Shapiro:

Every time I try to test this on historical data I get:

2019.08.17 20:38:02.707 2018.11.18 22:23:30   failed market sell 0.01 XXX [Unsupported filling mode]

It happens for any symbol I choose (FX or Stocks). No trading is performed. What could be the problem?


You may have a try to modify the "Order filling mode" input parameter. Let it meet the spec of the symbol of your broker.

How to check the filling mode of the symbol:

Go to "Market Watch" -> Select symbol and right click it ->Click the "Specification..." menu item -> Check the "Filling" description.

 

don't you think that a much larger takeout is a way to fail?

What prevents to trade in profit in the channel, for example, 20 pips stop and take and 20 pips take?

Account on the real is drained - I do not exclude because of this at least...

" The second signal was opened quite recently on a real account. At the time of writing it is trading only on stock market instruments: SBUX, MCD, KO, MSFT, NKE, ORCL, ADBE, CMCSA, LLY, HPE. "

The far takeout - speaks of greed, I think first of all, and especially as you described in the article like, that on the starting volume the price takes a very long time to get to THAT takeout....

 
Why can't this EA complete the test in MT5, the logs don't show errors, only constant requotes but no transactions, can anyone complete the test? Can you tell me what is going on?
 
Ben Shapiro:

Every time I try to test this on historical data I get:

2019.08.17 20:38:02.707 2018.11.18 22:23:30   failed market sell 0.01 XXX [Unsupported filling mode]

It happens for any symbol I choose (FX or Stocks). No trading is performed. What could be the problem?


Read the source Luke!

switch(useORDER_FILLING_RETURN){
   case FOK:
      mrequest.type_filling = ORDER_FILLING_FOK;
      break;
   case RETURN:
      mrequest.type_filling = ORDER_FILLING_RETURN;
      break;
   case IOC:
      mrequest.type_filling = ORDER_FILLING_IOC;
      break;
}

The code is very nice. Choose your filling mode. Broker friendly :)

 
Arthur Albano:

Read the source Luke!

The code is very nice. Choose your filling mode. Broker friendly :)

The code is really neat for a cross-platform, with time-series and all, BUT, I am trying to dig which Ask/Bid price my MT4 tester (build 1260) gets for this code to open trades. Each attempt of OrderSend ends with error 138 (New Prices), as if the MqlTick structure produces a wrong Ask/Bid for the tick?? or is it pulling the data from alt. timeframes? - I ran it at all the same timeframes as the operational tf, and it's still the same.

Does anybody here who tried the EA, experience similar problem and what may be the reason for error 138 in the tester?

Also, as the problem above, filling an order at market price (as could be the only option for a broker/instrument) doesn't seem an option in this EA, at least for MQL4 compillation:

#ifdef __MQL5__ 
   #include <Trade\Trade.mqh>
   CTrade Trade;

   enum TypeOfFilling // Filling Mode
     {
      FOK,//ORDER_FILLING_FOK
      RETURN,// ORDER_FILLING_RETURN
      IOC,//ORDER_FILLING_IOC
     }; 
   input TypeOfFilling  useORDER_FILLING_RETURN=FOK; // Order filling mode
#endif

(but I shouldn't show my arrogance by asking if such a choise is required for MT5 platform... ;-)


Also, not being a programmer myself, I came across a sample of code where it is postulated that ..'Running on every incoming tick is mandatory for strategy tester, but real-time processing is best onTimer event - standard 200 ms.'   How does this may affect the EA performance, particularly a multi-timeframe like this one?

Thank you forany comment on the above.

The Fundamentals of Testing in MetaTrader 5
The Fundamentals of Testing in MetaTrader 5
  • www.mql5.com
The idea of ​​automated trading is appealing by the fact that the trading robot can work non-stop for 24 hours a day, seven days a week. The robot does not get tired, doubtful or scared, it's is totally free from any psychological problems. It is sufficient enough to clearly formalize the trading rules and implement them in the algorithms, and...
 
rmshau:

The code is really neat for a cross-platform, with time-series and all, BUT, I am trying to dig which Ask/Bid price my MT4 tester (build 1260) gets for this code to open trades. Each attempt of OrderSend ends with error 138 (New Prices), as if the MqlTick structure produces a wrong Ask/Bid for the tick?? or is it pulling the data from alt. timeframes? - I ran it at all the same timeframes as the operational tf, and it's still the same.

Does anybody here who tried the EA, experience similar problem and what may be the reason for error 138 in the tester?

Also, as the problem above, filling an order at market price (as could be the only option for a broker/instrument) doesn't seem an option in this EA, at least for MQL4 compillation:

(but I shouldn't show my arrogance by asking if such a choise is required for MT5 platform... ;-)


Also, not being a programmer myself, I came across a sample of code where it is postulated that ..'Running on every incoming tick is mandatory for strategy tester, but real-time processing is best onTimer event - standard 200 ms.'   How does this may affect the EA performance, particularly a multi-timeframe like this one?

Thank you forany comment on the above.

This topic is about MQL5, you don't seem to know what platform you are using.

Anything concerning MT4 should be posted in the MT4 section.

 
That's what happened to mine.
 
fxsaber number of trades falls.

It is also possible to take out these returns directly in the Tester, making an ordinary TS in one line.

Bottom line.

As a result, I can't understand where I am wrong in my conclusion. All refilling TSs are a kind of self-deception - profit reduction. I am not talking about the drain in the form of a poker, but about profit reduction. After all, it is possible to pull out a more profitable TS from any refilling TS. It seems that everything is logically correct in this conclusion. But I can't understand why I am not sure, since I had such an experiment.

I don't see the same conclusion. Input number two has no memory, as well as the following ones, which means its MO is the same as any other input in this TC, i.e. zero. It is like waiting for the fifth black after the fourth red, only because the probability of 5 reds in a row is negligible. In reality, we have the same 50/50, which means that trading with martin or such a grid requires infinite capital to get a guaranteed fixed return.

 
Vasiliy Sokolov #:

I don't see the same conclusion. Input number two has no memory, as well as the following ones, and therefore its MO is the same as any other input in this TS, i.e. equal to zero. It is like waiting for the fifth black after the fourth red, only because the probability of 5 reds in a row is negligible. In reality, we have the same 50/50, which means that trading with martin or such a grid requires infinite capital to get a guaranteed fixed return.

I guess you misinterpreted my words.

 
equal to
12345
New comment