Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Понятно, что сделали обнуление для совместимости, но непонятно почему при правильной инициализации неиспользуемых enum = WRONG_VALUE - неправильно работает. При таком подходе отсутствует переносимость и существенно повышается вероятность скрытых ошибок.
Помните вот это правило?
Правило: если именованной константе - члену перечисления явно не присвоено конкретное значение, то ее значение будет сформировано автоматически. Если это первый член перечисления, то будет присвоено значение 0. Для всех последующих членов значения будет вычисляться на основе значения предыдущего члена путем прибавления единицы.
Скорее всего, проверка правильности заполнения полей запроса исходит из того, что значение члена перечисления не может быть отрицательным. При этом возможность присвоения члену перечисления значения WRONG_VALUE - не учтена.
При этом возможность присвоения члену перечисления значения WRONG_VALUE - не учтена.
Думаю, что в этом как раз и заключается ошибка. Если конкретный enum не используется - логично, что его значение будет WRONG_VALUE , а не например ORDER_TYPE_BUY, которое на самом деле = 0
а главное - ничто не мешает изменить логику работы OrderCheck() и OrderSend() сохранив при этом совместимость
а главное - ничто не мешает изменить логику работы OrderCheck() и OrderSend() сохранив при этом совместимость
Обнаружил странный "баг".
Я использую в советники данный код:
Одиночный прогон в тестере проходит без проблем, но как только я выставляю подбор параметров полным перебором, то тестер начинает в десять-цать раз работать медленнее. Мне непонятно почему при одном прогоне скорость адекватная, а при оптимизации скорость заметно падает. Причём падает она в геометрической прогресси. По процентам видно, что вначале идёт всё как надо, но ближе к финалу скорость всё ниже и ниже. Я искал проблему в своём коде на предмет зацикливания или ещё чего, но не нашел. После заменил выше приведённый код на свой алгоритм и о чюдо! Оптимизация теперь проходит с нормальной равномерной скоростью. От сюда я делаю вывод, что проблема внутри MQL5, гдето в теле функции OnTradeTransaction. Прошу разработчиков обратить на это внимание.
p.s. код эксперта выкладывать нет возможности. он для меня имеет ценность. Попробуйте использовать выше упомянутый код в любом своём советнике и посмотреть на скорость оптимизации по OHLC M5 на периоде с 2000 года по сегодняшний день.
Обнаружил странный "баг".
Я использую в советники данный код:
Одиночный прогон в тестере проходит без проблем, но как только я выставляю подбор параметров полным перебором, то тестер начинает в десять-цать раз работать медленнее. Мне непонятно почему при одном прогоне скорость адекватная, а при оптимизации скорость заметно падает. Причём падает она в геометрической прогресси. По процентам видно, что вначале идёт всё как надо, но ближе к финалу скорость всё ниже и ниже. Я искал проблему в своём коде на предмет зацикливания или ещё чего, но не нашел. После заменил выше приведённый код на свой алгоритм и о чюдо! Оптимизация теперь проходит с нормальной равномерной скоростью. От сюда я делаю вывод, что проблема внутри MQL5, гдето в теле функции OnTradeTransaction. Прошу разработчиков обратить на это внимание.
p.s. код эксперта выкладывать нет возможности. он для меня имеет ценность. Попробуйте использовать выше упомянутый код в любом своём советнике и посмотреть на скорость оптимизации по OHLC M5 на периоде с 2000 года по сегодняшний день.
При разных параметрах эксперт может работать разное время
После заменил выше приведённый код на свой алгоритм
Т.е. отказались от использования OnTradeTransaction() ? - тогда логично, что скорость возросла - она вызывается по каждому поводу
А что мешает сделать минимальный тест-кейс и отписаться в сервис-деск?