MetaTrader 5 Strategy Tester! - страница 25
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Urain:
Но мой вариант тоже не стоит сбрасывать со счёта, простой пользователь и так пасует перед сложностью MQL5 а тут ещё нагрузить работой с тестером, вообще утонет. При первом варианте, пользователь не знакомый с MQL5, думаю будет иметь шанс освоить язык сценариев.
1. Боюсь тогда он утонет в MQL5, а сверху надгробным камушком ляжет тот самый язык сценариев.
2. В любом случае управление тестером подобным образом должно быть делом индивидуальным - Хочешь пользуйся, не хочешь даже не заморачивайся подобными вещами.
1. И так, я пока что в ветке услышал два варианта реализации.
1. Отдельный язык сценариев (управление тестером) встроенный в тестер. Максимально упрощённый так чтоб даже не программист легко разобрался.
2. Полномасштабная реализация API управления тестером из MQL5. Как положено с событиями доступом к результатам, прерываниям тестирования итд.
2. Мне конечно нравится вариант komposter'а, тем более что MQ анонсировали увеличение настроек ГА, и чтоб не запутывать пользователей можно внешне оставить как есть, а дополнительное управление передать в API управления тестером из MQL5.
3. Но мой вариант тоже не стоит сбрасывать со счёта, простой пользователь и так пасует перед сложностью MQL5 а тут ещё нагрузить работой с тестером, вообще утонет. При первом варианте, пользователь не знакомый с MQL5, думаю будет иметь шанс освоить язык сценариев.
1. Да. 2. Да, и 3. Да.
Действительно, образовалось два варианта реализации, да, вариант управления тестером из mql5 выглядит необычайно привлекательно, и действительно, всё начиналось с простой идеи примитивного скриптового языка а-ля "*.bat", примерно соответствующего возможностям конфигурационного файла, на который сослался Rosh на 23 странице темы - ..ну может быть чуть покруче - с возможностью проанализировать результаты предыдущей оптимизации, перед тем как осмысленно (в соответствии с полученными результатами) запустить следующую оптимизацию. Я даже как-то организовывал опрос общественности, с целью выяснить, насколько сообщество mql5-юзеров заинтересовано в такой фиче.
Не знаю, пойдут ли разработчики на предоставление доступа к тестеру из mql5-скриптов (экспертов). У меня есть сомнения, поскольку подобные просьбы звучали неоднократно и разработчики на них не реагировали. Для меня это верный признак "большого геммороя" с точки зрения разработчиков. Т.е. сделать несложно, сложно разгребать последствия...
// Stringo, поправьте пожалуйста, если я промахнулся на этот счёт.
Поэтому предлагаю пока абстрагироваться от реализации (слишком рано конкретизировать) и действительно сосредоточиться на Use Case - вариантах использования.
Это самая важная печка от которой нужно плясать как от корня. ДЛЯ ЧЕГО (для каких пирожков) ЭТО ВСЁ НАДО.
Пока поделюсь своими запросами. Чего хотелось бы мне? Для каких задач мне это уже сегодня было бы очень кстати? // Потом, конечно, идеи появятся ещё.., намного жирнее..
1. Послойная сборка нейросеток. У меня есть наработки по требованиям предъявляемым к "хорошим" нейронам первого слоя. OnTester способен их выявлять и присваивать им высокий рейтинг. Аналогично дело обстоит и со вторым слоем и с третьим (если он понадобится). НО. Для "дрессировки" одного "хорошего" нейрона требуется два полных цикла оптимизации с совершенно различными параметрами. Небольших по продолжительности, но всё же... (: Почему два цикла объяснять не буду - тема жутко секретная :) А нейронов нужно как минимум пара десятков для первого слоя + вдвое меньше для второго, и штуки три для третьего. Итого - я насчитал по минимуму 66 запусков оптимизации на цикл сборки нейро-эксперта.
При этом: (1) Нельзя ошибаться. Что необычайно трудно, если учеть необычайную же нудность всего цикла с "бытовой" точки зрения. Этот простой факт сразу же делает автоматизацию крайне желательной. Автоматы тем и ценны, что способны избавлять от подобной рутины и справляться с ней безошибочно (если правильно запрограммированы, разумеется)...
(2) Желательно после завершения генерации первого слоя, встроить его в заготовку второго эксперта (например в виде сгенерированного моим скриптом инклюдника) и скомпилировать перед запуском серии оптимизаций, генерирующей нейроны второго слоя. Это очень желательно, чтобы обеспечить приемлемую скорость последующей оптимизации, ибо в противном случае, нейроны придётся грузить из файла перед каждым проходом оптимизатора. Я, конечно, не помру, если штатный вызов компилятора командной строки из bat-скрипта не будет реализован. Либо как нибудь выкручусь и таки смогу скомпилировать автоматически, либо просто оборву на этом цикл автооптимизаций, скомпилирую ручками, и ручками же запущу следующий тестер-скрипт...
2. Попроще. Чистая бытовуха, так сказать. Требуется исследовать потенциал экспериментального эксперта. При этом часть параметров нужно перебрать полным перебором, и для каждого варианта этого перебора сделать подгонку к истории другой группы параметров генетическим алгоритмом. Сейчас - вечер за компом, почти не слезая со стула. При наличии скриптового языка управления тестированием/оптимизацией - пара-тройка вложенных циклов for, с подстановкой счётчиков цикла в параметры оптимизации... и свободный вечер => счастливая семья.
3. Соптимизированного экперта нужно погонять на разных инструментах / периодах, дабы выяснить, с кем, в лице данного эксперта, имеем дело - с матёрым интеллектуалом или зубрилкой беспонтовым.... // вариант расширения идеи форвард тестирования.
--
Пока хватит. Подведу итоги. Итак, какие возможности мне требуются для реализации описанного выше:
1) Возможность многократно запускать одиночные прогоны тестера и циклы оптимизации в любой последовательности их чередуя и подставляя произвольные параметры (эксперт, инструмент, период, set-файл настроек).
2) Файловые операции. Например, чтение/анализ результатов тестирования/оптимизации из файла (если не будет прямого доступа к структурам с результатами в памяти, что было бы круче). Генерация set-файлов настройки. Генерация инклюдников, для стоящих в очереди кандидатов в советники... и т.д.
2.а) Доступ для файловых операций как в папке тестера, так и в папке MQL. А как же ещё положить инклюдник в одно нужное место, а set файл в другое... ?
3) Операторы циклов. Хотя бы один оператор.
4) Простейшие арифметические операции. Для расчёта параметров и прочих необходимостей.
5) Мда. Желательно таки запуск компиляции!
6) Генерация пользовательских событий из скрипта оптимизации. Кстати, это может сделать абсолютно ненужным дальнейшее развитие этого простого микроязыка. Всё остальное вполне сделают mql5-скрипты и эксперты, получившие долгожданное событие от тестера/оптимизатора.
Слава богу! Наконец-то появился запрос на макроязык тестера. А ведь это наиважнейшая вещь для разработчика-трейдера. Мой пример. Классический фарвард-анализ. Оптимизация на годовом периоде - выбор наилучшего варианта - тестирование на последующем двухмесячном периоде - передвижение по истории на 2 месяца и повторение цикла. И так лет за 10. И почти всё ручками, хотя операции до крайности тупые и механистичные. Нужен макроязык, который реализует то, что мы делаем на вкладках тестера: выбор советника, выбор периода тестирования/оптимизации, режим торговли и т. д. И желательно дохленькую СУБД для хранения и манипулирования входно/выходными данными советников. Сейчас всё пишу в EXEL. Почему внешний язык сценариев предпочтительней, чем запуск внутри MQL. Ну хотя бы, чтобы пользоваться советниками, сгенерированными Мастером. И вообще лучше мухи отдельно и котлеты тоже.
Если MQ предоставят возможность запускать экземпляр тестера из эксперта, они лучше знают, что у него на входе, что на выходе и дадут такой программный интерфейс каком им проще и удобней, вот тогда можно будет фантазировать на тему что делать и как лучше его использовать. Пока все это на уровне "ах если бы".
Конечно было бы лучше иметь структуру с параметрами тестирования: имя эксперта, все параметры тестера, массив структур с параметрами эксперта, режим (синхронный/асинхронный), а на выходе массив структур с результатами оптимизации или тестирования. Еще бы хорошо иметь доступ к внешним параметрам эксперта как к массиву структур параметров.
Самый большой вопрос - будет это вообще или нет, если нет - надо изобретать собственный велосипед с двумя терминалами, а если будет - можно расслабиться.
...
5) Мда. Желательно таки запуск компиляции!
...
С инклюдниками ты перемудрил, сетку можно сохранять в двоичный файл и компиляция не понадобится,
с остальным согласен.
...
Самый большой вопрос - будет это вообще или нет, если нет - надо изобретать собственный велосипед с двумя терминалами, а если будет - можно расслабиться.
Да, вопрос ???
Два терминала в виде матрёшки? верхний кнопкодав нижнего? или что то другое?
Да, вопрос ???
Два терминала в виде матрёшки? верхний кнопкодав нижнего? или что то другое?
Да. Только на кнопки не обязательно давить, можно через конфигурацию при старте (как в МТ4, не знаю в МТ5 есть или нет, но это точно будет, даже если пока и нет). Правда при тестировании такой метод будет тормознутым - пока терминал запустится, пока закроется...
С инклюдниками ты перемудрил, сетку можно сохранять в двоичный файл и компиляция не понадобится,
с остальным согласен.
С инклюдником наеборот недомудрил. Даже в описанном примере - сохранение я рассматривал и пробовал. Это тормозит оптимизацию следующего слоя, поскольку сетку приходится поднимать из файла при каждом пассе оптимизатора.
Но это только простейший пример. В более общем случае по результатам предыдущей оптимизации может быть просто сгенерирован новый советник. Это никакая не фантастика - ручками я это делаю. Естественно генерация на основе шаблона, который просто параметризуется при генерации. Но тем не менее - создаётся новый mql-советник и его, естесвенно, нужно скомпилять.
Так что позволю себе не согласиться - компиляция весьма желательна.
--
Кстати, я пропустил операторы if(..){..} и switch(..) {case..}.
Хотя бы if(){} нужен обязательно.
Да. Только на кнопки не обязательно давить, можно через конфигурацию при старте
1. (как в МТ4, не знаю в МТ5 есть или нет, но это точно будет, даже если пока и нет).
2. Правда при тестировании такой метод будет тормознутым - пока терминал запустится, пока закроется...
1. Есть, уже давно.
2. Вот именно!
К тому в такой технологии требуется "выделенный" терминал исключительно для оптимизации. На регулярно перезагружающемся терминале особо не поторгуешь.. :)
Неоправданный перерасход памяти налицо.
Столкнулся с описанной выше задачей (программное управление работой тестера) и стало очень интересно, будет ли в этом направлении что то делаться или нет?