Errors, bugs, questions - page 836

 
hrenfx:
Read the discussion.
Thanks for the link. I will copy my post there as it is on topic.
 
gpwr:

Holes have nothing to do with it. All trades are shifted by one bar regardless of the day of the week or time of day. There is a problem with synchronisation of quotes in the open price testing mode. When testing using the tickwise mode, trades are placed at required nests and everything works. But static testing takes much time for me. I do not know about others but optimization in tick-testing is simply impossible because of the great amount of time.

Ok, the way is not about the hole, though they will have an impact too... According to the given code, doesn't it happen that the ticks of a new bar for GBPUSD always (as a rule) come later than ticks of a new bar for EURUSD, and then there will be a shift by one bar in Bars function, depending on whether it's called by own or someone else's symbol? When there is a test for a new GBPUSD bar from EURUSD chart, the new GBPUSD bar is not there yet, although EURUSD is. It's a fixture of opening price testing.
 
marketeer:
Ok, the way is not about the hole, although they will also have an impact... According to the above code, isn't it the case that the ticks of a new GBPUSD bar always (usually) come later than the ticks of a new EURUSD bar, and then just one bar shift in the Bars function, depending on whether it is called by its own or someone else's symbol? When there is a test for a new GBPUSD bar from EURUSD chart, the new GBPUSD bar is not there yet, although EURUSD is. This is a testing feature based on opening prices.
It is quite possible. I do not know whether it is a feature or not, but it's definitely an error. Even if the tester detects a closing of GBPUSD bar from EURUSD chart with one bar delay, it would work properly, if trades were opened on the same delayed bar, but not after one bar. Judging by the lack of response since June, the administration does not seem to think this is a mistake.
 
gpwr:
It's quite possible. I don't know if it's a feature or not, but it's definitely a bug. Even if the tester detects GBPUSD bar closing from EURUSD chart with one bar delay, everything would work fine if trades were placed on the same delayed bar, not one bar later. Judging by the lack of response since June, the administration apparently doesn't think it's a mistake.
Exactly. On the forum somewhere there are already statements by the MC on this subject (it's a bit late to search now ;-) ).
 
If the optimized indicator contains the profit factor, the tester uses the value of infinity 1.#INF (1.#J) if there are only profits and no losses. At the same time, the optimization chart "goes crazy" and shows a blank. Who solves this problem? Or write to service-desk?
 
marketeer:
If the optimized indicator contains the profit factor, the tester uses the value of infinity 1.#INF (1.#J) if there are only profits and no losses. At the same time, the optimization chart "goes crazy" and shows a blank. Who solves this problem? Or may I need to write to Service Desk?
Let's write to Service Desk. We will solve the problem.
 
marketeer:
Ok, the way is not about the hole, although they will also have an impact... According to the above code, isn't it the case that the ticks of a new GBPUSD bar always (usually) come later than the ticks of a new EURUSD bar, and then just one bar shift in the Bars function depending on whether it is called by its own or someone else's symbol? When there is a test for a new GBPUSD bar from EURUSD chart, the new GBPUSD bar is not there yet, although EURUSD is. It's a testing fixture on the opening prices.
It's about modelling the opening prices. There are no ticks here at all
 
gpwr:

Holes have nothing to do with it. All trades are shifted by one bar regardless of the day of the week or time of day. There is a problem with synchronisation of quotes in the open price test mode. When testing using the tickwise mode, trades are placed at required nests and everything works. But static testing takes much time for me. I do not know about others but optimization in tick-testing is simply impossible because of the great amount of time.

By the way, I have applied for error of quotes synchronization in multicurrency back in June of this year. There have been a couple of updates to the terminal, but the error is still not fixed.

The "at open prices" mode has many architectural constraints, which was warned about in advance.

In your case, use M1 OHLC mode with new bar check (as it is done in our example Moving Averages)

 
stringo:
This is about modelling opening prices. There are no ticks at all.
You don't understand what I'm saying. The bars are derived from ticks, and the actual time of bar formation coincides with the time of the first tick in it.
 
marketeer:
You did not understand what I said. The bars are obtained by ticks, with the actual time of bar formation coinciding with the time of the first tick in it.
When testing "by opening prices", test bars are formed as a whole. No attention is paid here to what bar has begun to form earlier (in contrast to the Jety-Ox testing)
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы - Документация по MQL5