ФорумРазделы

Новая версия платформы MetaTrader 5 build 2940: Перенос витрин MQL5-сервисов в рабочую область и обновление дизайна - страница 14

Новый комментарий
Artyom Trishkin:

2957 есть уже

Спасибо. К сожалению, в b2957 проблема с дебагером не решена.

Уважаемые разработчики, сделайте доступ к стакану из сервиса.
Нужны функции MarketBookAdd(), MarketBookRelease(), MarketBookGet().
Алготрейдинг из сервиса разрешен, а доступа к стакану нет.

Уважаемые разработчики, 

будет ли реализован полноценный мост к криптобиржам? Хотя бы к Binance. Не хотелось бы пользоваться костылями. 

Хотелось бы понять принципиально - да, это будет или нет - мы этим заниматься не будем. 

user4321:

Уважаемые разработчики, 

будет ли реализован полноценный мост к криптобиржам? Хотя бы к Binance. Не хотелось бы пользоваться костылями. 

Хотелось бы понять принципиально - да, это будет или нет - мы этим заниматься не будем. 

Так платформу должен кто то купить, брокер, который обеспечит доступ клиентов через терминал и будет платить MQ, а крипто биржи работают без посредников, или уже нет?

При оптимизации получаю ошибку:

"

2021.06.11 05:24:31.158 Core 3 pass 328 tested with error "no memory in OnTick function (cannot get 1920 Kb, used 4287 Mb)" in 0:00:03.326

"

Одиночный проход работает корректно.

Памяти занято в районе 30% от 24 гигабайт.

Заканчивается крашем windows 7 - через черный экран и сообщением о нехватке памяти, терминал закрывается..
Aleksey Vyazmikin:

При оптимизации получаю ошибку:

"

2021.06.11 05:24:31.158 Core 3 pass 328 tested with error "no memory in OnTick function (cannot get 1920 Kb, used 4287 Mb)" in 0:00:03.326

"

Одиночный проход работает корректно.

Памяти занято в районе 30% от 24 гигабайт.

Заканчивается крашем windows 7 - через черный экран и сообщением о нехватке памяти, терминал закрывается..
Может семёрка сломалась?

Серьезная ошибка в работе с историей торгов.

// Скрипт показывает, что ордера в таблице истории (HistorySelect) 
// не отсортированы по ORDER_TIME_DONE_MSC-времени.

#property script_show_inputs

input datetime inFrom = 0; // С какого времени брать историю торгов

void OnStart()
{

  if (HistorySelect(inFrom, INT_MAX))
  {
    ulong Orders[]; // Массив со всеми историческими ордерами в той же последовательности, как в HistorySelect.
    
    const int Total = ArrayResize(Orders, HistoryOrdersTotal());
    
    // Заполнили массив.
    for (int i = 0; i < Total; i++)
      Orders[i] = HistoryOrderGetTicket(i);

    int Amount = 0;
      
    // Бежим по массиву
    for (int i = 1; i < Total; i++)
      if (HistoryOrderGetInteger(Orders[i - 1], ORDER_TIME_DONE_MSC) > // Если Done-время предыдущего ордера в таблице
          HistoryOrderGetInteger(Orders[i], ORDER_TIME_DONE_MSC))      // меньше текущего,
        Amount++;                                                      // ведем подсчет таких ситуаций.
        
    Print(Amount); // Сколько нашли странных последовательностей в таблице.
    Print(Total);  // Размер всей таблицы.
  }
}


Во время торговли в историческую таблицу ордеров попадают все новые и новые записи об ордерах. Логично, что только что исполненный/удаленный ордер должен дозаписываться в конец этой таблицы.

Т.е. если видите, что HistoryOrdersTotal увеличился на единицу, то последний элемент в HistorySelect-таблице ордеров и является только что исполненным/удаленным ордером. Иначе говоря, эти ордера в таблице отсортированы по своему Done-времени. Со сделками именно так обстоят дела. Однако, с ордерами - совсем нет.


Скрипт выше это показывает. Он просто подсчитывает, сколько ситуаций, когда в таблице ордер имеет Done-время больше, чем ордер, который стоит после него.


Результат запуска такой.

38512
114603

В таблице 38 тысяч записей именно такие из 114 тысяч - треть.


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

Правильно ли понимаю, что (за исключением правок задним числом) только что исполненный/удаленный ордер во время работы советника попадает в конец HistorySelect-таблицы - имеет самый большой индекс для HistoryOrderGetTicket?

fxsaber:

Серьезная ошибка в работе с историей торгов.


Во время торговли в историческую таблицу ордеров попадают все новые и новые записи об ордерах. Логично, что только что исполненный/удаленный ордер должен дозаписываться в конец этой таблицы.

Т.е. если видите, что HistoryOrdersTotal увеличился на единицу, то последний элемент в HistorySelect-таблице ордеров и является только что исполненным/удаленным ордером. Иначе говоря, эти ордера в таблице отсортированы по своему Done-времени. Со сделками именно так обстоят дела. Однако, с ордерами - совсем нет.


Скрипт выше это показывает. Он просто подсчитывает, сколько ситуаций, когда в таблице ордер имеет Done-время больше, чем ордер, который стоит после него.


Результат запуска такой.

В таблице 38 тысяч записей именно такие из 114 тысяч - треть.


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

Правильно ли понимаю, что (за исключением правок задним числом) только что исполненный/удаленный ордер во время работы советника попадает в конец HistorySelect-таблицы - имеет самый большой индекс для HistoryOrderGetTicket?

Всегда так было. Там скорее всего привязка к времени установки. Точнее уже не помню. Тоже думал, что последний сработавший должен быть последним в списке, но оказалось, что это далеко не так. Пришлось искать ордера, вместо получения последнего.

Artyom Trishkin:

Всегда так было. Там скорее всего привязка к времени установки. Точнее уже не помню. Тоже думал, что последний сработавший должен быть последним в списке, но оказалось, что это далеко не так. Пришлось искать ордера, вместо получения последнего.

Заменил в скрипте ORDER_TIME_DONE_MSC на ORDER_TIME_SETUP_MSC.

47
114630

Да, ордера отсортированы по времени установки. Это принципиальная ошибка! Очень прошу разработчиков высказаться по этому поводу. Жутко тормозной и нелогичный код получается, если нужно что-то отслеживать, синхронизировать и т.д. Такое ощущение, что это просто ошибка опечатки в коде: вместо Done написали Setup.

ЗЫ Похоже, время никак не анализировали. Просто по ORDER_TICKET сортировка. Для сделок это логично. Для ордеров - абсолютно нет!
fxsaber:

Заменил в скрипте ORDER_TIME_DONE_MSC на ORDER_TIME_SETUP_MSC.

Да, ордера отсортированы по времени установки. Это принципиальная ошибка! Очень прошу разработчиков высказаться по этому поводу. Жутко тормозной и нелогичный код получается, если нужно что-то отслеживать, синхронизировать и т.д. Такое ощущение, что это просто ошибка опечатки в коде: вместо Done написали Setup.

ЗЫ Похоже, время никак не анализировали. Просто по ORDER_TICKET сортировка. Для сделок это логично. Для ордеров - абсолютно нет!

Скорее всего, логика там такая из-за нескольких разных самостоятельных списков (ордера, сделки, позиции). Каждый список сортирован по (не помню точно) тикету (или времени? проверять нужно. Проверял, но уже забыл). Вот и вся логика. Три самостоятельных списка. Из позиции можно достать сделки, из сделок - ордера. Но каждый список самостоятелен и не зависит от соседних списков.

Почему так? Наверное это логично - вести три самостоятельных списка каждый со своей независимой сортировкой.

1...789101112131415161718192021...29
Новый комментарий