Технологическая сингулярность MetaTrader 5 - страница 3

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

https://www.mql5.com/ru/articles/3795

наслаждайтесь

В машинном обучении если вы ничего не понимаете то никакой движок вас не спасет. Это как раз та область где нужно понимать почти всю матчасть.

Мне ссылки не нужны.

Речь об огромном количестве трейдеров, которые никогда эту матчасть не выучат. Ждать от них этого бессмысленно.

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

 
Реter Konow:

Мне ссылки не нужны.

Речь об огромном количестве трейдеров, которые никогда эту матчасть не выучат. Ждать от них этого бессмысленно.

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


с вами все как обычно )

 
Anatoli Kazharski:

Каждый случай нужно рассматривать отдельно. Лучший способ показать своё виденье это продемонстрировать конечный результат. В данном случае, (1) что у вас получается при тесте на полном интервале и (2) что получается, если разбить весь интервал на 10 частей, провести отдельные тесты и суммировать их? Если сделок много и все они имеют короткий срок удержания, то результаты будут почти идентичными. Отличие только в том, что последняя сделка в конце теста на каждой из 10-ти частей может быть закрыта принудительно.

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

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

 
Stanislav Korotky:

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

Каким образом это можно сделать? То, что вы сейчас описали, совсем не то, что нужно получить. Поясню.

Например, провели оптимизацию, когда каждый проход проходил по полному интервалу. Допустим, оптимизацию проводим в режиме Только цены открытия или OHLC на M1 для экономии времени, при условии, что результаты в этих режимах и в режиме Все тики/Каждый тик на основе реальных тиков не сильно отличаются. Но в итоге, после оптимизации параметров, при выборе нужных сетов для последующей работы нам нужно смотреть финальные результаты в режиме Все тики/Каждый тик на основе реальных тиков. Если сделок очень много, допустим сотни тысяч, то вся эта процедура занимает довольно много времени. Хотелось бы по максимуму экономить время на всём. Если бы была возможность проводить такой тест, начиная его из нескольких точек одновременно, используя многоядерность, то тест проходил бы в несколько раз быстрей.

 
Anatoli Kazharski:

Каким образом это можно сделать? То, что вы сейчас описали, совсем не то, что нужно получить. Поясню.

Например, провели оптимизацию, когда каждый проход проходил по полному интервалу. Допустим, оптимизацию проводим в режиме Только цены открытия или OHLC на M1 для экономии времени, при условии, что результаты в этих режимах и в режиме Все тики/Каждый тик на основе реальных тиков не сильно отличаются. Но в итоге, после оптимизации параметров, при выборе нужных сетов для последующей работы нам нужно смотреть финальные результаты в режиме Все тики/Каждый тик на основе реальных тиков. Если сделок очень много, допустим сотни тысяч, то вся эта процедура занимает довольно много времени. Хотелось бы по максимуму экономить время на всём. Если бы была возможность проводить такой тест одновременно начиная его из нескольких точек одновременно, используя многоядерность, то тест проходил бы в несколько раз быстрей.


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

У меня есть библиотека форвард-оптимизации, которая по этому принципу работает и строит кумулятивный форвард прогон, составленный из нескольких мелких окон (диапазонов дат).

 
Stanislav Korotky:

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

У меня есть библиотека форвард-оптимизации, которая по этому принципу работает и строит кумулятивный форвард прогон, составленный из нескольких мелких окон (диапазонов дат).

В любом случае это будет полный интервал. Лишнее время будет отнимать проход от начала общего интервала к тестовому участку. Чистый тест эксперта-пустышки в режиме Все тики на интервале от 1999 года занимает больше минуты:

void OnTick(void) {}
connecting to 127.0.0.1:3000
connected
authorized (agent build 1708)
EURUSD,M1 (MetaQuotes-Demo): testing of Experts\Test.ex5 from 1999.01.01 00:00 to 2017.12.15 00:00
common synchronization completed
quality of analyzed history is 98%
login (build 1708)
account info found
1482 bytes of tester parameters loaded
initial deposit 10000.00 USD, leverage 1:500
successfully initialized
345 bytes of total initialization data received
Intel Core i7-4770  @ 3.40GHz, 8075 MB
EURUSD,M1: history cached from 1998.01.02 00:00
EURUSD,M1 (MetaQuotes-Demo): every tick generating
EURUSD,M1: testing of Experts\Test.ex5 from 1999.01.01 00:00 to 2017.12.15 00:00 started
final balance 10000.00 USD
EURUSD,M1: 207959916 ticks, 6782448 bars generated. Test passed in 0:01:16.985.
969 Mb memory used including 429 Mb of history data, 320 Mb of cached tick data (total memory for tick data 3839 Mb)
...

//---

Сэкономить в этом случае можно принудительно обрывая тест в конце участков, удаляя эксперта. На схеме ниже жёлтые участки показывают потраченное впустую время:


//---

Нужно, чтобы тест начинался сразу от начала каждого тестируемого участка, позволяя экономить максимум времени. Что вы можете предложить в этом случае?

 

Отличные новости касающиеся тестера:

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Бета-версия платформы MetaTrader 5 build 1700: Проекты в MetaEditor и синтетические инструменты

Renat Fatkhullin, 2017.12.15 11:58

Мы кардинально улучшим и ускорим тестер.

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

По частичному исполнению пока ничего говорить не буду, надо думать.

 
Anatoli Kazharski:

В любом случае это будет полный интервал. Лишнее время будет отнимать проход от начала общего интервала к тестовому участку.

Сэкономить в этом случае можно принудительно обрывая тест в конце участков, удаляя эксперта. На схеме ниже жёлтые участки показывают потраченное впустую время:

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

Для более эффективного решения в рамках тестера - обращайтесь к MQ.

 
Stanislav Korotky:

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

...

Речь идёт о максимально возможной экономии. И о возможностях, которые распространяются для всех и сразу с максимально возможным качеством. Тем более это касается отчётов тестера.

Stanislav Korotky:

...

Для более эффективного решения в рамках тестера - обращайтесь к MQ.

Эта ветка и есть обращение к MQ. После того, как её закрепили можно даже в сервисдеск не дублировать. 


//---

Здесь интересны мысли и предложения от всего сообщества по развитию тестера стратегий и торговой платформы MetaTrader 5.

 

Что касается развития платформы.

Сделано уже столько всего, что лично мне трудно придумать что еще нужно. Однако, я бы хотел напомнить о новом типе программ. Кажется, их называют "сервисы". Не знаю точно что под этим подразумевают, но вот что мне бы хотелось:

"Сервисы" должны быть "параллельными" программами. Они должны легко синхронизироваться с любым пользовательским приложением (советником, индикатором, скриптом) и выполнять работу с их параметрами.

Например:

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


В общем, нужен штатный метод синхронизации между приложением и сервисом.

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