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

 
fxsaber:
В логах привел точные результаты. Сам МРЧ не мой, поэтому не разбираюсь досконально.
Жаль, придется всё таки использовать таблицу с ранжированием по критериям... Придется учитывать соотношение результата и количество обращений.
 
Andrey Dik:
Жаль, придется всё таки использовать таблицу с ранжированием по критериям... Придется учитывать соотношение результата и количество обращений.
Так а зачем эту таблицу делать? MQ уступает уже двум MQL-реализациям - это очевидно. При чем МРЧ очень лаконичный и публичный в исходниках.
 
fxsaber:
Так а зачем эту таблицу делать? MQ уступает уже двум MQL-реализациям - это очевидно. При чем МРЧ очень лаконичный и публичный в исходниках.
Так то оно да...  А с текстом тест МПЧ провалил? Ярко выраженные дискретные задачи с независимыми параметрамм он похоже "недолюбливает", а это как мы знаем типичные трейдерские задачи. 
В любом случае, картина складывается не в пользу алгоритма от MQ, если учитывать его весьма ограниченную область поиска. 

 
Andrey Dik:
Так то оно да...  А с текстом тест МПЧ провалил?
Похоже, что так.
 
Интересно, что МРЧ делает 1000 итераций за 1.5 мс и получает результат ~0.995. Это много круче MQ
 
fxsaber:
Интересно, что МРЧ делает 1000 итераций за 1.5 мс и получает результат ~0.995. Это много круче MQ

Это хороший результат. Но напомню, что результат был получен на очень простом тесте с 2-мя переменными. А конкретно эти цифры говорят о том, что алгоритм МРЧ очень хорошо распределяет начальные усилия на широкий диапазон параметров и быстро находит "большую яму", но хуже сходится в одной глобальной точке.

К тому же для функций с такими как эта, с малым количеством параметров 1-4, можно использовать стратегию "делим на 2" или стратегию "делим на 3". Подобные простейшие стратегии поиска покажут ещё бОльшую сходимость на начальных обращениях к ФФ, но они не справятся с дискретными задачами типа "текст" и с задачами многих параметров.

А так как мы рассматриваем показатели универсальных алгоритмов оптимизации, то алгоритм от MQ справляется с "универсальностью" весьма неплохо, в то время как МРЧ задачу с текстом завалил, алгоритм MQ его прошел. На данный момент глобальный недостаток алгоритма MQ я вижу только в ограниченном поле поиска, если не учитывать этот крупный недостаток, то он показывает себя весьма достойно на фоне других алгоритмов.

Следующим тестом, в ракурсе "лучший универсальный алгоритм", будет тест со многими параметрами используя предыдущую функцию с двумя параметрами "размноженной" на все остальные параметы ФФ и со смещёнными "большими ямами". Во во первых, это сразу покажет недостатки алгоритмов "делим на 2" из за смещения глобального максимума и наличия многих параметров, а так же проверим способность также хорошо находить окрестность глобального максимума алгоритма МРЧ в этих условиях. 

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

 
Andrey Dik:

А так как мы рассматриваем показатели универсальных алгоритмов оптимизации, то алгоритм от MQ справляется с "универсальностью" весьма неплохо, в то время как МРЧ задачу с текстом завалил, алгоритм MQ его прошел. На данный момент глобальный недостаток алгоритма MQ я вижу только в ограниченном поле поиска, если не учитывать этот крупный недостаток, то он показывает себя весьма достойно на фоне других алгоритмов.

Меня не особо напрягает, что MQ-алгоритм уступает Вашему и довольно существенно. Бесит, что многоядерные мат. оптимизации в MQ производятся на порядки медленней по времени.

Неприятно, что Облако за деньги медленней на мат. задачах, чем free-лаконичные в реализации алгоритмы. Т.е. использовать Облако для мат. расчетов имеет смысл только в том случае, если одиночный расчет ФФ занимает огромное время. А это сверх-низкая часть от всех мат. расчетов. Пакетирование, как в случае с полным перебором, здесь не прокатит.

Фактически, Облако для мат. расчетов целесообразно только при полном переборе.

MD5 Cloud Decryptor
MD5 Cloud Decryptor
  • голосов: 29
  • 2015.05.02
  • MetaQuotes
  • www.mql5.com
Этот пример показывает принцип использования механизма передачи кастомных фреймов данных с агентов во время массового перебора паролей в задаче поиска MD5 хешей. В режиме реального времени показываются скоростные характеристики расчетной сети и прогресс выполнения. Другой особенностью программы является демонстрация принципа виртуализации входных нелинейных и нечисловых параметров в числовой счетчик.
 
fxsaber:

Меня не особо напрягает, что MQ-алгоритм уступает Вашему и довольно существенно. Бесит, что многоядерные мат. оптимизации в MQ производятся на порядки медленней по времени.

Неприятно, что Облако за деньги медленней на мат. задачах, чем free-лаконичные в реализации алгоритмы. Т.е. использовать Облако для мат. расчетов имеет смысл только в том случае, если одиночный расчет ФФ занимает огромное время. А это сверх-низкая часть от всех мат. расчетов. Пакетирование, как в случае с полным перебором, здесь не прокатит.

Фактически, Облако для мат. расчетов целесообразно только при полном переборе.

Да, согласен.

Но, возможно, обсуждения проблем и проведение тестов покажут узкие места тестера и оптимизатора и заострят внимание MQ на проблемных местах, хочется в это верить. В этом я вижу пользу от данной дискуссии.  

 
Andrey Dik:

Да, согласен.

Но, возможно, обсуждения проблем и проведение тестов покажут узкие места тестера и оптимизатора и заострят внимание MQ на проблемных местах, хочется в это верить. В этом я вижу пользу от данной дискуссии.  

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

Реальные тики в текущем виде годятся только для мультивалютного бэктеста.

Кастомные данные в полном забвении. А ведь за счет них можно было бы ускорять бэктесты на порядки с минимальными потерями в точности.

 
Andrey Dik:

Верхняя зона явно выделяется на фоне остальных, я бы исключил её из претендентов на выбор в качестве рабочего варианта. Нижняя зона отпадает как убыточная. Выделяю зелёным зону, в которой на мой взгляд подходят на роль рабочих вариантов. А теперь вопрос, как выделить эти варианты из зелёной зоны в списке вкладки "Оптимизация"? Да никак! А было бы очень удобно на манер выбора зоной магазинов на карте (банкоматов, кафе, ресторанов) как предоставляют такую возможность некоторые онлайн карты. Выбрал квадратиком или кругом зону параметров - и вот они уже в списке "Оптимизация" а остальные скрыты.

Полностью поддерживаю! Возможность сохранения диапазонов оптимизации в файл существенно сократила бы время затраченное на оптимизацию.
Причина обращения: