MetaTrader 5 Strategy Tester! - страница 24

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

Мне кажется, идеальным решением будет запуск процесса тестирования/оптимизации из MQL 5.

На входе - структура настроек (Советник, Валютная пара, ТФ, Временной промежуток, и т.д.).

На выходе - структура результатов (или массив структур в случае оптимизации).


А дальше все решает фантазия программиста.

Хочешь - периодически оптимизируй, хочешь - сортируй результаты и делай форвард, хочешь - выбирай область параметров и запускай подробную оптимизацию.


При занятом тестере предусмотреть постановку в очередь или просто возврат ошибки.

Возможно, не лишней будет и галочка "Разрешить советнику/скрипту использовать тестер" в настройках.


Что скажете?

 
komposter:

Мне кажется, идеальным решением будет запуск процесса тестирования/оптимизации из MQL 5.


Вроде как через WinAPI запустить тестер с параметрами можно и сейчас, другое дело если для запуска тестера и обработки результатов использовать только MQL.

Тогда я за пожалуй, только идею нужно будет более детально обсудить.

Насколько я понимаю при запуске нужно только указать имя файла с параметрами, а вот как определить что тестирование закончилось и обработать результаты (особенно оптимизацию) это вопрос...


 

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

А уже из примеров можно будет обрисовать функциональные потребности.

Я привёл такой пример: из-за большого количества параметров с начало делается запуск с крупным шагом на больших пределах, а затем обработав результаты локализуется область и подбираются уточнённые параметры.

Какие ещё варианты использования могут быть?

Ещё пример: Оптимизируются параметры, затем обрабатываются результаты и находится область повышенной прибыльности, после чего делается запуск оптимизации в найденной области но уже не на прибыль, а на наименьшую просадку.

 
Interesting:

Вроде как через WinAPI запустить тестер с параметрами можно и сейчас, другое дело если для запуска тестера и обработки результатов использовать только MQL.

Через АПИ можно все. Хоть загрузить историю котировок и самостоятельно протестировать стратегию.

Только к чему это? Мы же обсуждаем удобство, а не возможность. Запускать МТ с ini-файлом можно было еще в 4-й версии, только костыль это, а не решение.

 

Urain:

Какие ещё варианты использования могут быть?

  • Пакетное тестирование/оптимизация (по определенному набору инструментов) с любыми вариантами форвардов.
  • Поэтапная оптимизация с любым деревом выбора параметров.
  • Тестирование "на лету" при внесении изменений в код.
  • Периодическое тестирование и публикация результатов.
  • ...

Наверное, можно много всего придумать. Но, как по мне, это не с той стороны заход.

Нужна обычная функция (как ОрдерСенд): передаем параметры, получаем результаты.


Как выглядел бы опрос "Какие варианты использования ОрдерСенд вы видите"? Глупо, не так ли? ;)

 
komposter:

Через АПИ можно все. Хоть загрузить историю котировок и самостоятельно протестировать стратегию.

Только к чему это? Мы же обсуждаем удобство, а не возможность. Запускать МТ с ini-файлом можно было еще в 4-й версии, только костыль это, а не решение.

Согласен, нужно иметь возможность вызвать тестер с необходимыми параметрами параметрами из эксперта только при помощи MQL.

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


 
komposter:

...идеальным решением будет запуск процесса тестирования/оптимизации из MQL 5.

На входе - структура настроек (Советник, Валютная пара, ТФ, Временной промежуток, и т.д.).

На выходе - структура результатов (или массив структур в случае оптимизации). 

Именно так. У пользователя должна быть возможность запустить обработчик события OnTester(), который, в свою очередь, отрабатывает весь пользовательский сценарий работы с тестером. А со структурами на входе и выходе можно будет реализовать самые фантастические сценарии. В общем, в поддержку идеи, предлагаю включить в функционал всего лишь одну функцию  
bool EventOnTester( 
   MqlTesterSet&    set,   // структура настроек
   MqlTesterResult& result // структура результата
  );
Функция, с моей токи зрения, должна быть асинхронная: запустил и забылся... Т.е. функция запускает копию эксперта в тестере, а работа самого эксперта не должна прерываться на время оптимизации. Все сценарии оптимизации должны отрабатываться в OnTester(). Для обработчика OnChartEvent() можно придумать событие оповещающее об окончании оптимизации и о том, что  структура результата заполнена. Ну... еще нужна функция рестарта советника с новыми параметрами.
 
Lizar:
Именно так. У пользователя должна быть возможность запустить обработчик события OnTester(), который, в свою очередь, отрабатывает весь пользовательский сценарий работы с тестером. А со структурами на входе и выходе можно будет реализовать самые фантастические сценарии. В общем, в поддержку идеи, предлагаю включить в функционал всего лишь одну функцию 
Функция, с моей токи зрения, должна быть асинхронная: запустил и забылся... Т.е. функция запускает копию эксперта в тестере, а работа самого эксперта не должна прерываться на время оптимизации. Все сценарии оптимизации должны отрабатываться в OnTester(). Для обработчика OnChartEvent() можно придумать событие оповещающее об окончании оптимизации и о том, что  структура результата заполнена. Ну... еще нужна функция рестарта советника с новыми параметрами.

1. На мой взгляд при таком подходе лучше разнести структуры по отдельным местам. Структуру настроек (или просто имя файла с нстройками указать при запуске тестера), а результирующую структуру поулучить скажем не в nChartEvent() а в качестве параметра в OnTester().

Остается вопрос что конкретно поместить в эту структуру?

2. Но я бы задумался о другом варианте, примерно таком:

а. Запускаем тестирование, обычным способом или из MQL (в данном случае нам интересен второй вариант).

б. При тестировании мы можем получать информацию о текущем прогоне при помощи MQL5InfoInteger и TesterStatistics

в. По завершению тестирования, скажем OnTester() с параметром в виде структуры условно названной MqlTesterResult (в эту структуру будет записана определенная полезная информация, а также информация о том завершено тестирование запущенное из MQL или выполняемое обычным способом).

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

Такую информацию можно анализировать либо в OnTester() либо в OnDeinit().



 

И так, я пока что в ветке услышал два варианта реализации.

1. Отдельный язык сценариев (управление тестером) встроенный в тестер. Максимально упрощённый так чтоб даже не программист легко разобрался.

2. Полномасштабная реализация API управления тестером из MQL5. Как положено с событиями доступом к результатам, прерываниям тестирования итд.

Мне конечно нравится вариант komposter'а, тем более что MQ анонсировали увеличение настроек ГА, и чтоб не запутывать пользователей можно внешне оставить как есть, а дополнительное управление передать в API управления тестером из MQL5.

Но мой вариант тоже не стоит сбрасывать со счёта, простой пользователь и так пасует перед сложностью MQL5 а тут ещё нагрузить работой с тестером, вообще утонет. При первом варианте, пользователь не знакомый с MQL5, думаю будет иметь шанс освоить язык сценариев.


 
Interesting:

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

Но возник более удачный вариант (изменятся пункты 2в и 3)

в. По завершению тестирования, генерируется событие, которое поступает скажем в void OnTimer(const MqlTesterResult Res[]). Организация структур в динамический массив обеспечит нам обобщение информации по определенному количеству проходов.

3. Наличии массиива из структур с результатами по отдельному проходу оптимизации (или одним проходом в случаи одиночного тестирования) позволит проанализировать результаты оптимизации в  OnTimer.

Также в качестве параметров для OnTimer можно предусмотреть и другие данные (тут уже речь скорей о детальной проработке).

4. Структура MqlTesterResult Res может содержать либо специализированную информацию (тут вопрос к разработчикам) либо максимально совпадать с тем что возвращает

О максиимальном количестве записей в динамическом массиве MqlTesterResult Res тоже не лишним будет подумать.

PS

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

1...171819202122232425262728293031...99
Новый комментарий
Причина обращения: