Новая версия платформы MetaTrader 5 build 4620: исправления ошибок в MQL5 и новые методы OpenBLAS - страница 9

Новый комментарий
 
Stanislav Korotky #:

Может и не использоваться, в данном случае ревизия 0, но таких записей две - видимо, глюк:

Скорее всего глюк, поскольку у них и время выхода совпадает. Но показатели не совсем совпадают.
 
Aleksey Nikolayev #:

Пытался использовать его для отбора самого первого по времени значения индикатора. Не надо заводить массив с показателями за один и тот же период с последующим отбором самого раннего по времени выхода. Правда, оказалось, что есть события совпадающие как по номеру ревизии, так и по обоим временам (периода и выхода), что совсем не здорово.

Календарь так не работает. Когда для события появляется обновление информации, поставщики заменяют информацию в той же самой записи и увеличивают номер ревизии, то есть отследить историю изменений одной записи непосредственно из статического (на момент X) календаря - нельзя. Это действительно представляет проблему, потому что в динамике у эксперта была одна информация в момент выхода новости, а спустя какое-то время эта информация может быть отредактирована, и именно на ней мы будем потом тестировать.

Чтобы отловить изменения в алгокниге даже был представлен сервис CalendarChangeSaver.mq5. Но чтобы сохраненные данные можно было использовать в тестере, нужно (было уже давно) крутить сервис в режиме 365*24.

Сейчас, например, сравниваю архив календаря за 2022 год с тем, что выдается на то время теперь, и уже во многих местах стоят другие показатели, даже поле impact меняет знак кое-где.

 
Stanislav Korotky #:

Календарь так не работает. Когда для события появляется обновление информации, поставщики заменяют информацию в той же самой записи и увеличивают номер ревизии, то есть отследить историю изменений одной записи непосредственно из статического (на момент X) календаря - нельзя. Это действительно представляет проблему, потому что в динамике у эксперта была одна информация в момент выхода новости, а спустя какое-то время эта информация может быть отредактирована, и именно на ней мы будем потом тестировать.

Чтобы отловить изменения в алгокниге даже был представлен сервис CalendarChangeSaver.mq5. Но чтобы сохраненные данные можно было использовать в тестере, нужно (было уже давно) крутить сервис в режиме 365*24.

Сейчас сравниваю архив календаря за 2022 год с тем, что отдается сейчас, например, и уже во многих местах стоят другие показатели, даже поле impact меняет знак кое-где.

По вашему получается, что событий с одним id (вида события) и с одним временем периода должно быть ровно одно. Но это не так - их довольно много и в большинстве своём они различаются по номеру ревизии.

Тех что совпадают и по времени периода и по номеру ревизии довольно мало и почти все они различимы по времени прихода.

Тех что совпадают по всем трём параметрам (время прихода, номер ревизии и время периода) совсем мало - несколько штук.

 
Aleksey Nikolayev #:

По вашему получается, что событий с одним id (вида события) и с одним временем периода должно быть ровно одно. Но это не так - их довольно много и в большинстве своём они различаются по номеру ревизии.

Тех что совпадают и по времени периода и по номеру ревизии довольно мало и почти все они различимы по времени прихода.

Тех что совпадают по всем трём параметрам (время прихода, номер ревизии и время периода) совсем мало - несколько штук.

Например, вот это выдаст около сотни строк. Скорее всего конечно, это глюк, поскольку ревизии только с номерами 1 и 3. Если бы это была фича а не баг, то должны быть и ревизии 0 и 2.

Но как-то работать с этим надо же?

void OnStart()
{  MqlCalendarValue values[];
   int n = CalendarValueHistoryByEvent(840020006, values, 0);
   for (int i = 0; i < n - 1; ++i)
      for (int j = i + 1; j < n; ++j)
         if (values[i].period == values[j].period)
            printf("event#%d revision#%d and event#%d revision#%d", i, values[i].revision, j, values[j].revision); //
}
 
Aleksey Nikolayev #:

В базе календаря есть записи с совпадающим временем отчётного периода и одним и тем же номером ревизии. Запускалось на метаквотовском демо.

Удалили дубликат

 
MetaQuotes:

В пятницу 11 октября 2024 года будет выпущена обновленная версия платформы MetaTrader 5.

В этом выпуске мы исправили несколько трудноуловимых ошибок MQL5, что позволит сделать работу ваших программ еще более стабильной...

Сегодня заметил что по итогам обновления до версии 4620 всплыла еще одна трудноуловиямая ошибка - Самопроизвольная де-регитстрация кастомарных символов.

Краткое описание бага:

- в терминале МТ5 были созданы8 кастомарных символов, представляющих собой склеееные фьючерсы на СМЕ (6A,6E,6B,6N,JPY,CAD,CHF,MXN,GCc), и запушен советник-копировщик баров М1 из базовых инструментов в эти кастомарные символыж

- по итогам обновления до версии 4620 в меню "Symbols" в разделе "Custom" часть символов пропала - 6A,6E,6B,6N,JPY, а часть  осталась ( CAD,CHF,MXN,GCc ), что собствено я и назвал Самопроизвольной де-регитстрация кастомарных символо;

- при этом в "Market Watch" пропавшие кастомарные символы можно найти и выбрать для работы, на их основе выводятся графики и строятся индикаторы, и советник-копировщик продолжает успешно работать, т.е. функции CustomTicksAdd() CustomRatesUpdate() продолжают нормально с ними работать.

Для изучения и устранения бага прилагаю скрин-шот терминала, файл "symbols.custom.dat" (возможно что сбой произошел именно в нем) и файл лога системы.

Файлы:
MT5_CS-Dereg-20241025.jpg  533 kb
symbols.custom.zip  8 kb
20241025.log  42 kb
 
Aleksey Nikolayev #:

По вашему получается, что событий с одним id (вида события) и с одним временем периода должно быть ровно одно. Но это не так - их довольно много и в большинстве своём они различаются по номеру ревизии.

Тех что совпадают и по времени периода и по номеру ревизии довольно мало и почти все они различимы по времени прихода.

Тех что совпадают по всем трём параметрам (время прихода, номер ревизии и время периода) совсем мало - несколько штук.

Не, это не по моему. Это какая-то вольная интерпретация. Я не знаю норм по поводу количества событий одного вида за конкретный отчетный период и ничего об этом не говорил (вообще не использовал поле "период" никогда). Полагаю, что есть виды событий, для которых допустимо несколько выпусков за отчетный период - у них должно быть разное дата/время (!). В том фрагменте, что я приводил, налицо глюк, потому что времена публикации полностью совпадают.

Повторю свою мысль (на основе того, что узнал от MQ): для конкретной записи календаря (конкретного события, а не вида события) не сохраняется история правок, а сам факт исправления отражается в увеличении номера ревизии.

Нам вряд ли удастся узнать, почему у некоторых событий больше ревизий, чем у других. Я бы не зацикливался на конкретных числах (1, 3 или что-то еще). Если поставщик каким-то скриптом поправит события конкретного вида, то все номера ревизий синхронно увеличатся.

 
MetaQuotes #:

Удалили дубликат

Хорошо. Если не сложно, прокомментируйте тогда результат из сообщения выше - это баг или ожидаемое поведение? Там по прежнему выдаётся около сотни пар событий за один период и с разными ревизиями (1 и 3).
 
Aleksey Nikolayev #:
Хорошо. Если не сложно, прокомментируйте тогда результат из сообщения выше - это баг или ожидаемое поведение? Там по прежнему выдаётся около сотни пар событий за один период и с разными ревизиями (1 и 3).

Примеры (для наглядности):

194957,840020006,2024.09.27 15:30:00,T,2024.08.01,1,,L,Wholesale Inventories m/m,USD,US,0.2,0.2,0.3,0.2
194958,840020006,2024.10.09 17:00:00,T,2024.08.01,3,+,L,Wholesale Inventories m/m,USD,US,0.1,0.2,nan,0.2
197533,840020006,2024.10.29 15:30:00,T,2024.09.01,1,,L,Wholesale Inventories m/m,USD,US,nan,0.1,nan,-0.3
194960,840020006,2024.11.07 18:00:00,T,2024.09.01,3,,L,Wholesale Inventories m/m,USD,US,nan,nan,nan,nan

А вот что говорит всемогущий интернет:

US Wholesale Inventories m/m

There are 2 versions of this indicator released about a week apart - Preliminary and Final.

 
Stanislav Korotky #:

Не, это не по моему. Это какая-то вольная интерпретация. Я не знаю норм по поводу количества событий одного вида за конкретный отчетный период и ничего об этом не говорил (вообще не использовал поле "период" никогда). Полагаю, что есть виды событий, для которых допустимо несколько выпусков за отчетный период - у них должно быть разное дата/время (!). В том фрагменте, что я приводил, налицо глюк, потому что времена публикации полностью совпадают.

Повторю свою мысль (на основе того, что узнал от MQ): для конкретной записи календаря (конкретного события, а не вида события) не сохраняется история правок, а сам факт исправления отражается в увеличении номера ревизии.

Нам вряд ли удастся узнать, почему у некоторых событий больше ревизий, чем у других. Я бы не зацикливался на конкретных числах (1, 3 или что-то еще). Если поставщик каким-то скриптом поправит события конкретного вида, то все номера ревизий синхронно увеличатся.

Значит домыслил за вас, за что извиняюсь.

Всё как обычно - дело ясное, что дело тёмное.

12345678910111213141516...26
Новый комментарий