Обновление платформы MetaTrader 4 build 670: виртуальный хостинг, web-запросы и работа с сигналами из MQL-программ - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Судя по постам здесь, в основном заботят не трейдинговые фишки новых билдов, а возникающие трудности при выполнении фриланс-заказов. Редкие трейдинговые моменты игнорятся не только разрабами, но и остальной частью сообщества.
Все же хотелось бы вспомнить, что терминал является не только инструментом фрилансеров и их заказчиков, но и, наверное, алготрейдерским инструментом. Посему хочется разобраться в причинах странной архитектуры оптимизатора/тестера.
Очень неудобно, что так называемый "тестер" может быть либо бэктестером одиночного прогона, либо оптимизатором набора одиночных прогонов. Одновременно и тем и тем - не может быть.
А ведь так логично (и удобно), когда во время длительного оптимизационного процесса можно выбрать понравившийсся по показателям вариант входных параметров одиночного прогона и посмотреть его подробно - прогнать в бэктестере. Но, к сожалению, бэктестер недоступен, когда работает оптимизатор. Интересно, что для такого функционала совершенно не требуется какой-либо параллельности, либо же два приложения в одном. Достаточно просто за очередным прогоном оптимизатора добавить нужный прогон тестера. Т.е. нужны минимальные изменения в текущих билдах для такого функционала. При этом данная реализация никак не скажется на ГА и прочих возможных оптимизационных нюансах.
Но, наверное, количество людей, кто это может по достоинству оценить, ничтожно мало, чтобы повлиять на развитие продукта для массового пользователя.
Еще не в курсе, появилась ли возможность расчета кастомных статистических показателей результатов прогона и вывода их не только в "Отчет", но и в закладку "Результаты оптимизации". Однако, давно и логично зреет желание некоторой кучки пользователей иметь в наборе ну хотя бы еще ОДИН такой показатель - фактор восстановления. При том, что он не требует хоть сколько-нибудь существенных доп. расчетов - разделить уже посчитанный Profit на уже посчитанный MaxDD.
Эта возможность есть
OnTester
Функция OnTester() является обработчиком события Tester, которое автоматически генерируется по окончании исторического тестирования эксперта на заданном интервале дат. Функция должна быть определена с типом double, параметров не имеет:
double OnTester();
Функция вызывается непосредственно перед вызовом функции OnDeinit() и имеет тип возвращаемого значения double. Функция OnTester() может быть использована только в экспертах при тестировании и предназначена в первую очередь для расчета некоторого значения, используемого в качестве критерия Custom max при генетической оптимизации входных параметров.
При генетической оптимизации сортировка результатов в пределах одного поколения производится по убыванию. То есть, лучшими с точки зрения критерия оптимизации считаются результаты с наибольшим значением (для критерия оптимизации Custom max в расчет принимаются значения, возвращенные функцией OnTester). Худшие значения при такой сортировке помещаются в конец и впоследствии отбрасываются и не принимают участия в формировании следующего поколения.
Сейчас условие исполнения SellLimit в тестере (у разрабов) прописано следующим образом:
А надо бы так:
Для BuyLimit - по аналогии. Есть возражения?Отуда взялся High с предыдущего бара?
МТ4-670 - Пытаюсь импортировать минутную историю 2001-2014, пишет что не хватает памяти.
Есть файл содержащий минутную историю 2001-2013, который более ранними версиями (до 5хх серии) грузился без проблем,
новая версия не в состоянии. Разбил файл на две части, половинка загружается, но не дело так работать, тем более что раньше проблем не возникало. WinXP SP3, 4 GB памяти.
Чтобы доказать правоту вышесказанного нашел версию МТ4-445, без проблем импортировал в нее "проблемный" файл исторических данных 2001-2014, создал *.hst, которые уже скормил МТ4-670. Пожалуйста, исправьте баг в новой версии.
Так есть свойство CHART_FOREGROUND (https://docs.mql4.com/ru/constants/chartconstants/enum_chart_property). Или Вы имеете в виду что-то другое?
Отуда взялся High с предыдущего бара?
Речь идет о режиме тестера "по ценам открытиям". В этом режиме MT4-тестер проверяет, нужно ли исполнять отложенные ордера или нет, в момент, когда появляется новый бар. Т.е. новый (нулевой) бар в этот момент проверки имеет только одну цену - Open[0]. При этом идет еще проверка с ценами предыдущего бара, которые до сих пор не проверялись - High и Low.
У вас есть сверка в некоторых случаях даже с Close-ценой, но уже не для отложенных напрямую ордеров, а для косвенно-отложенных - SL/TP уровней. Это нужно для таких ситуаций, когда, например, SellLimit имеет сразу выставленный TP. За счет High[1] >= SellLimit_OpenPrice SellLimit превращается в SELL. А за счет SELL_TP >= Close[1] + Spread закрывается. Т.е. проверка Close[1] у вас в тестере осуществляется для ловли ситуаций, когда отложенный ордер внутри бара открылся и закрылся. Но я изначально веду речь о напрямую отложенных ордерах, поэтому Close[1] для них у вас нигде и не светится.
Именно из-за особенностей такой проверки в режиме "по ценам открытия" время исполнения отложенных ордеров на одну единицу ТФ позже, чем время бара, на котором он должен был сработать. Например, если High[1] >= SellLimit_OpenPrice, то время исполнения MT4-тестер покажет равным не Time[1], а Time[0]. Что на самом деле является здравым решением.
Однако, из-за неправильного условия сравнения, которое написал выше, иногда получается так, что отложенник исполняется по цене Open[1] == High[1]. Т.е. если на предыдущем баре, когда уже, конечно, известна Open[1] выставить SellLimit на ценовой уровень Open[1]. То при проверке исполнения получится, что отложенник исполнится по цене, которая была до выставления SellLimit в случае, если Open[1] == High[1]. Что, конечно же, ни есть хорошо.
Отсутствие учета такого нюанса с уменьшением ТФ увеличивает количество таких ошибок исполнения, т.е. чем меньше ТФ, тем больше ситуаций, где Open[1] == High[1] или Open[1] == Low[1]. Например, если бы у вас был бы ТФ < 1 минуты (10 секунд), то можно было бы с легкостью написать тестерный грааль на отложенных ордерах в режиме "по ценам открытия". При этом заметьте, что при такой логике велся бы явный учет конрольных точек. Т.е. никакого мухлежа не использовалось бы, как происходит в режима "по всем тикам", когда используют минусы штатного генератора тиков.
Точно также тестерные граали могут рождаться и на слаболиквидных символах даже на M1, если спред на них невысокий. Просто слаболиквидные символы имеют относительно низкую частоту изменения своей цены, поэтому баров, у которых Open == High или Open == Low значительный процент. Убедиться в этом можно, посмотрев M1-график какой-нибудь экзотики.
Надеюсь, доходчиво расписал. Такая же проблема, скорее всего, касается и MT5-тестера, как и большинство существующих тестеров.
Эта возможность есть
OnTester
Функция OnTester() является обработчиком события Tester, которое автоматически генерируется по окончании исторического тестирования эксперта на заданном интервале дат. Функция должна быть определена с типом double, параметров не имеет:
double OnTester();
Функция вызывается непосредственно перед вызовом функции OnDeinit() и имеет тип возвращаемого значения double. Функция OnTester() может быть использована только в экспертах при тестировании и предназначена в первую очередь для расчета некоторого значения, используемого в качестве критерия Custom max при генетической оптимизации входных параметров.
Спасибо. Наличие задания кастомного критерия оптимизации - это хорошо. Спрашивал, правда, о несколько другом функционале. В закладки "Результаты оптимизации" и "Отчет" есть ли возможность добавить хотя бы один кастомный показатель прогона (больше одного, как понял, нельзя, т.к. onTester возвращает лишь один double) в виде столбика значений? При этом не задавая критерием оптимизации Сustom (например, выбрав классический Balance).
Ну и есть ли возможность в onTester получить уже посчитанные самим тестером MaxDD, PF и прочее, чтобы самому не делать лишние (повторные) вычисления?
Кстати, наверное, ошибаюсь, но если бы onDeinit возвращал бы тот же double, то необходимость в onTester отпала бы сама собой. Перемудрили, похоже.
Предусмотрена ли кастомная возможность прерывания прогона при оптимизации, по аналогии с этим:
Что-то вроде StopBackTester(). Нужно, т.к. штатный список очень топорный и использовать его эффективно получается только через искусственный вызов (еще один танец с бубном) события прерывания прогона из штатного списка (см. картинку).