Ошибки, баги, вопросы - страница 891

 

Понятно, что сделали обнуление для совместимости, но непонятно почему при правильной инициализации неиспользуемых enum = WRONG_VALUE - неправильно работает. При таком подходе отсутствует переносимость и существенно повышается вероятность скрытых ошибок.

 
A100: непонятно почему при правильной инициализации неиспользуемых enum = WRONG_VALUE - неправильно работает.

 Помните вот это правило?

Правило: если именованной константе - члену перечисления явно не присвоено конкретное значение, то ее значение будет сформировано автоматически. Если это первый член перечисления, то будет присвоено значение 0. Для всех последующих членов значения будет вычисляться на основе значения предыдущего члена путем прибавления единицы.

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

 
Yedelkin:

 При этом возможность присвоения члену перечисления значения WRONG_VALUE - не учтена.

Думаю, что в этом как раз и заключается ошибка. Если конкретный enum не используется - логично, что его значение будет WRONG_VALUE , а не например ORDER_TYPE_BUY, которое на самом деле = 0

а главное - ничто не мешает изменить логику работы OrderCheck() и OrderSend() сохранив при этом совместимость

 
A100: Думаю, что в этом как раз и заключается ошибка. Если конкретный enum не используется - логично, что его значение будет WRONG_VALUE , а не например ORDER_TYPE_BUY, которое на самом деле = 0

а главное - ничто не мешает изменить логику работы OrderCheck() и OrderSend() сохранив при этом совместимость

 Есть возможность понять мнение разработчиков - написать об ошибке в Сервисдеск. 
 

Обнаружил странный "баг".

Я использую в советники данный код:

void OnTradeTransaction(const MqlTradeTransaction &trans, const MqlTradeRequest &request, const MqlTradeResult &result)
  {
   if(trans.type == TRADE_TRANSACTION_DEAL_ADD)
    {
     if(trans.symbol == "EURUSD") EURUSD_K = 1;
    }    
  }

 Одиночный прогон в тестере проходит без проблем, но как только я выставляю подбор параметров полным перебором, то тестер начинает в десять-цать раз работать медленнее. Мне непонятно почему при одном прогоне скорость адекватная, а при оптимизации скорость заметно падает. Причём падает она в геометрической прогресси. По процентам видно, что вначале идёт всё как надо, но ближе к финалу скорость всё ниже и ниже. Я искал проблему в своём коде на предмет зацикливания или ещё чего, но не нашел. После заменил выше приведённый код на свой алгоритм и о чюдо! Оптимизация теперь проходит с нормальной равномерной скоростью. От сюда я делаю вывод, что проблема внутри MQL5, гдето в теле функции OnTradeTransaction. Прошу разработчиков обратить на это внимание.

p.s. код эксперта выкладывать нет возможности. он для меня имеет ценность. Попробуйте использовать выше упомянутый код в любом своём советнике и посмотреть на скорость оптимизации по OHLC M5 на периоде с 2000 года по сегодняшний день. 

Документация по MQL5: Основы языка / Функции / Функции обработки событий
Документация по MQL5: Основы языка / Функции / Функции обработки событий
  • www.mql5.com
Основы языка / Функции / Функции обработки событий - Документация по MQL5
 
lordlev:

Обнаружил странный "баг".

Я использую в советники данный код:

 Одиночный прогон в тестере проходит без проблем, но как только я выставляю подбор параметров полным перебором, то тестер начинает в десять-цать раз работать медленнее. Мне непонятно почему при одном прогоне скорость адекватная, а при оптимизации скорость заметно падает. Причём падает она в геометрической прогресси. По процентам видно, что вначале идёт всё как надо, но ближе к финалу скорость всё ниже и ниже. Я искал проблему в своём коде на предмет зацикливания или ещё чего, но не нашел. После заменил выше приведённый код на свой алгоритм и о чюдо! Оптимизация теперь проходит с нормальной равномерной скоростью. От сюда я делаю вывод, что проблема внутри MQL5, гдето в теле функции OnTradeTransaction. Прошу разработчиков обратить на это внимание.

p.s. код эксперта выкладывать нет возможности. он для меня имеет ценность. Попробуйте использовать выше упомянутый код в любом своём советнике и посмотреть на скорость оптимизации по OHLC M5 на периоде с 2000 года по сегодняшний день. 

При разных параметрах эксперт может работать разное время
 
Konstantin83:
При разных параметрах эксперт может работать разное время
В данном случае проблема не в эксперте, и не в параметрах. Проблема в самом MQL5.
 
lordlev:

После заменил выше приведённый код на свой алгоритм

Т.е. отказались от использования OnTradeTransaction() ? - тогда логично, что скорость возросла - она вызывается по каждому поводу
 
A100:
Т.е. отказались от использования OnTradeTransaction() ? - тогда логично, что скорость возросла - она вызывается по каждому поводу
Отказался естественно. Это понятно что она вызывается при любом поводе. Просто непонятно почему при одиночном прогоне скорость адекватная, а при оптимизации скорость резко падает. И дело тут не в самих параметрах как пишет выше другой товарищ это я досканально проверил раз на десять. От сюда и вывод, что гдето закралась ошибочка со стороны разработчиков.
 
lordlev:

А что мешает сделать минимальный тест-кейс и отписаться в сервис-деск?

Причина обращения: