Как ускорить оптимизацию (перебор) в тестере? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Пользователь может настраивать приоритеты по агентам? Например, если нужно передавать много данных на агенты, выбирать те, что не только быстрые, но и имеют скорость интернета соответствующую.
Т.е. может ли пользователь задавать кастомный критерий (формулу) выбора агентов для своих расчетов?
Вы бы документацию поизучали чтоль. Ничего из описанного вами там нет. Хотя не спорю, было бы полезно иметь такие возможности. Самого часто бесит, что из-за нескольких тормозных агентов приходится подолгу ждать завершения оптимизации.
Допустим, одиночный проход в тестере занимает минуту (уже за вычетом времени на подготовку тестером истории и другого торгового окружения).
В оптимизаторе ставлю перебор двух входных параметров - каждый по 10 значений. Итого 100 вариантов.
Есть ли в тестере какие-то внутренние алгоритмы, которые делают такой перебор менее, чем за 100 минут?
Например, если каждый входной параметр независим и является параметром разных индикаторов. Тогда можно сущетсвенно экономить на вычислениях, полагая, что показания одного из индикаторов считать на многих проходах не нужно - раньше были посчитаны.
Ну и вопрос ко всем, какие рекомендации можете дать для ускорения перебора в оптимизаторе? Записывать в файл и считывать - принимается.
Недооценивать такую алгоритмическую оптимизацию не стоит. Иногда в тысячи раз получается ускорения с обычными файлами, вместо пересчета индикаторов с одними и теми же параметрами. Так что облако даже рядом не стояло.
Ну а по облаку интересно, кто-нибудь делал алгоритмическую оптимизацию, которая бы работала и на облаке? Идея через файлы должна же работать и через облачный сервис.
Спрашиваю, т.к. не пользовался еще ни тестером, ни оптимизатором, ни облаком. Но собираюсь попробовать мультивалютку. Думаю, как бы универсально избежать громоздких повторных вычислений.
Перечитал ветку, в обсуждении есть решение, даже есть постановка задачи, и есть обозначение условий при которых стоит решать задачу через сохранение в файл уже готовых данных, но упущен ещё один момент.
Упущен расчёт времени на реализацию варианта с сохранением рассчитанных данных в файл.
Теперь смотрите что получается: вошли в одиночный проход, сверились есть ли файл с данными для текущей настройки, если есть то читаем файл, если нет считаем свои данные, далее если данные типа есть то нужно определить мы находимся на агенте или на домашней машине, если на агенте то данные нужно получать из фрейма. Плюс ко всем этим радостям нужно потратить время чтоб всё это закодировать (тк задача не шаблонная, не часто используемая, то придётся проверять и перепроверять результаты на предмет валидности). Опять же нужно будет определить среднее время для пересылки фрейма (тк у разных агентов оно будет разное).
А теперь скажите честно, может быть правы были предыдущие ораторы, рекомендовавшие вам изначально не изобретать велосипеды, считать всё налету и пользоваться ГА ?
И главное, и тут вас ждёт разочарование, mql5 настолько заоптимизирован на скорость расчётов что в большинстве случаев расчёт налету будет быстрее чем достать данные из файла. Если же расчёт настолько тяжёл что предыдущее утверждение неверно, то это хороший повод задуматься а оптимален ли алгоритм расчёта, нет ли в нём мест которые можно оптимизировать. И лишь получив отрицательный ответ, приступать к поиску ухищрений.
И главное, и тут вас ждёт разочарование, mql5 настолько заоптимизирован на скорость расчётов что в большинстве случаев расчёт налету будет быстрее чем достать данные из файла. Если же расчёт настолько тяжёл что предыдущее утверждение неверно, то это хороший повод задуматься а оптимален ли алгоритм расчёта, нет ли в нём мест которые можно оптимизировать. И лишь получив отрицательный ответ, приступать к поиску ухищрений.
Добавлю. Учитывая саму специфику деятельности, бывает, что советник использует схожие параметры - простой пример - использование сигнала на пересечение двух МА. Логично, что для сигнала не важно первая или вторая МА будет иметь оптимальные параметры (допустим пересечение 100 и 50 МА), а полный перебор заставит перебрать все МА - логичней сделать алгоритм исключения, согласно которому перебор будет только уникальных значений.
Так же такой метод оправдан при установке диапазонов в осцилляторах, служащих для подтверждения сигнала - тут существенный эффект.
Эффект исключения паразитарных прогонов дает существенный прирост в скорости поиска оптимальных настроек.
К сожалению, программист, с которым мы это реализовали давно тут не появлялся. А я детали по коду рассказать не могу.
В этом случае все, кто добрался бы до этих настроек, включил все по максимуму, и не думал бы о нагрузке на сеть. И слабые агента вообще выпали бы из процесса.
А теперь скажите честно, может быть правы были предыдущие ораторы, рекомендовавшие вам изначально не изобретать велосипеды, считать всё налету и пользоваться ГА ?
И главное, и тут вас ждёт разочарование, mql5 настолько заоптимизирован на скорость расчётов что в большинстве случаев расчёт налету будет быстрее чем достать данные из файла. Если же расчёт настолько тяжёл что предыдущее утверждение неверно, то это хороший повод задуматься а оптимален ли алгоритм расчёта, нет ли в нём мест которые можно оптимизировать. И лишь получив отрицательный ответ, приступать к поиску ухищрений.
Фреймовая передача - не оптимальное рещение, как мне видится. Пакетирование и создание локальных файлов - другое дело.
ГА - это решение другой задачи, никак не связанной с сабжем. Объяснял это несколько раз, насколько мог.
У меня есть тяжелые мультивалютные расчеты и они разве только в OpenCL не оптимизированы. Алгоритмы близки к оптимальным.
Считывание из файла - это концепция больше, нежели прямое считывание с диска. Если бы данные писались в область памяти, которая доступна при следующем проходе - то дисковые файлы остались бы неудел. И такое решение давало бы ощутимый выигрышь, по сравнению с пересчитыванием.
К сожалению, разработчики совсем не предусмотрели возможности алгоритмической оптимизации процесса перебора в тестере. Хотя, это напрашивается сразу.
Возможности собственного управления перебираемыми параметрами есть: https://www.mql5.com/ru/docs/optimization_frames/parametersetrange
Можно самому задать пределы переборов перед началом теста. Например на основе собственной логики, нечисловых настроек или чтением из файла взять и назначить некоторые параметры перебираемыми.
Имея нечисловые/нелинейные входные данные можно их по своей формуле завернуть в один последовательный гигантский long счетчик, а внутри проходов уже разворачивать очередное long значение счетчика в соответствующий набор нелинейных/своих параметров.
Этот функционал специально заложен нами для неограниченной вариабельности нечисловых входных данных.
Например, в файле прописаны хитрые наборы данных(мегабайты всякой сложности, блоки данных и тд), в ините читаете данные из файла, выставляете числовые пределы специальным выделенным счетчикам, а потом запускаете простую задачу "посчитать простые рейнджи".
Уловили идею?
Этот функционал специально заложен нами для неограниченной вариабельности нечисловых входных данных.
Например, в файле прописаны хитрые наборы данных(мегабайты всякой сложности, блоки данных и тд), в ините читаете данные из файла, выставляете числовые пределы специальным выделенным счетчикам, а потом запускаете простую задачу "посчитать простые рейнджи".
Уловили идею?
Допустим, одиночный проход в тестере занимает минуту (уже за вычетом времени на подготовку тестером истории и другого торгового окружения).
В оптимизаторе ставлю перебор двух входных параметров - каждый по 10 значений. Итого 100 вариантов.
Представьте, что у вас неограниченные вычислительные мощности. Вы получаете моментом все ваши 100 вариантов. Но дальше - вам нужно в любом случае отобрать наилучший (наибольший по балансу, наименьший по просадке и так далее). Суть в том, чтобы формализовать этот критерий. Любой алгоритм, уменьшающий количество переборов, должен уметь из двух вариантов выбрать лучший. Вот этот самый критерий необходимо заложить в тестер - и можно запустить хоть полный перебор, хоть генетический алгоритм. Генетика - позволит найти приемлемые варианты в большинстве случаев, и при этом количество прогонов будет значительно меньше, чем при полном переборе вариантов.
Ваша проблема, на мой взгляд, в том, что вы не понимаете, что вам надо. Когда в тестировании участвует критерий "я чувствую" - это уже не тестирование, а гадание на кофейной гуще.
Вам надо четко формализовать, как вы из двух вариантов выбираете лучший.