Как ускорить оптимизацию (перебор) в тестере? - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Уловил идею, как возможность перебирать нелинейно. Но совершенно не уловил, каким боком это вписывается в контекст данной ветки. Вроде, первый пост не касается этой идеи.
Просто для информации, да и близко к обсуждаемой теме.
Мало кто знает о таких возможностях тестера.
Просто для информации, да и близко к обсуждаемой теме.
Мало кто знает о таких возможностях тестера.
Представьте, что у вас неограниченные вычислительные мощности. Вы получаете моментом все ваши 100 вариантов. Но дальше - вам нужно в любом случае отобрать наилучший (наибольший по балансу, наименьший по просадке и так далее). Суть в том, чтобы формализовать этот критерий. Любой алгоритм, уменьшающий количество переборов, должен уметь из двух вариантов выбрать лучший. Вот этот самый критерий необходимо заложить в тестер - и можно запустить хоть полный перебор, хоть генетический алгоритм. Генетика - позволит найти приемлемые варианты в большинстве случаев, и при этом количество прогонов будет значительно меньше, чем при полном переборе вариантов.
Ваша проблема, на мой взгляд, в том, что вы не понимаете, что вам надо. Когда в тестировании участвует критерий "я чувствую" - это уже не тестирование, а гадание на кофейной гуще.
Вам надо четко формализовать, как вы из двух вариантов выбираете лучший.
Умение растолковать - талант. И я им не обладаю, иначе бы вы не написали этого. Остается только попросить еще раз перечитать этот пост.
Перебору не нужен критерий оптимизации. Перебор - это не задача оптимизации: на мат языке "минимизация целевой функции". Для чего нужен именно перебор и насколько он может быть полезен, написал выше.
Ясных аргументов подобрать не могу, иначе бы подрабатывал лектором )) Может, кто-нибудь разделяет мою точку зрения и не поленится аргументировать со своей стороны.
В упор не вижу обозначенной вами проблемы.
Если дать пользователям возможность выбрать только самые мощные агенты, все именно так и сделают. А что тогда будут считать более слабые?
Кстати, возможность проверить агент на некоторые ресурсы можно. Например, TERMINAL_MEMORY_AVAILABLE и TERMINAL_DISK_SPACE. В случае недостатка ресурсов нужно из OnInit вернуть INIT_AGENT_NOT_SUITABLE.
Умение растолковать - талант. И я им не обладаю, иначе бы вы не написали этого.
Нужно было акцентировать внимание на том, что задача - ускорить полный перебор. Не оптимизацию, а именно полный пересчет.
Это не очевидно.
И главное, и тут вас ждёт разочарование, mql5 настолько заоптимизирован на скорость расчётов что в большинстве случаев расчёт налету будет быстрее чем достать данные из файла. Если же расчёт настолько тяжёл что предыдущее утверждение неверно, то это хороший повод задуматься а оптимален ли алгоритм расчёта, нет ли в нём мест которые можно оптимизировать. И лишь получив отрицательный ответ, приступать к поиску ухищрений.
Уловил идею, как возможность перебирать нелинейно. Но совершенно не уловил, каким боком это вписывается в контекст данной ветки. Вроде, первый пост не касается этой идеи.
Смотрите: делаете советник в котором вызывается ваш тяжёлый индикатор, результат расчёта индикатора сообщаете через кастомную фитнес функцию нагора, через управление результатами выгружаете результаты расчётов многих проходов в один файл у себя на машине. Запускате советник в клауд на полный перебор. Получаете файл в котором настройке индикатора соотвествует готовый результат. если индикаторов несколько то процедуру повторить для каждого (получите по файлу полного перебора для каждого индикатора).
Затем пишите советник для проверки торговли, он уже запускается не в клауде а на домашней машине, расчитанные данные индикаторов такой советник берёт их файлов индикаторов, те уже готовые, поэтому оптимизация пойдёт быстро даже без облака (облако свою работу сделало). И тут уже не будет разницы будут ли проходы с одинаковыми настройками или нет.
Если дать пользователям возможность выбрать только самые мощные агенты, все именно так и сделают. А что тогда будут считать более слабые?
Смотрите: делаете советник в котором вызывается ваш тяжёлый индикатор, результат расчёта индикатора сообщаете через кастомную фитнес функцию нагора, через управление результатами выгружаете результаты расчётов многих проходов в один файл у себя на машине. Запускате советник в клауд на полный перебор. Получаете файл в котором настройке индикатора соотвествует готовый результат. если индикаторов несколько то процедуру повторить для каждого (получите по файлу полного перебора для каждого индикатора).
Затем пишите советник для проверки торговли, он уже запускается не в клауде а на домашней машине, расчитанные данные индикаторов такой советник берёт их файлов индикаторов, те уже готовые, поэтому оптимизация пойдёт быстро даже без облака (облако свою работу сделало). И тут уже не будет разницы будут ли проходы с одинаковыми настройками или нет.
Без обид, это обсуждалось почти сразу:
Классаня идея посчитать значения тяжелых независимых индикаторов на тысячах агентов и через фреймы перегнать себе на комп. А потом уже на локальном оптимизаторе работыть с этими индикаторами исключительно, как с файлами. Облако всего один раз надо будет использовать Спасибо за наводку!
Если дать пользователям возможность выбрать только самые мощные агенты, все именно так и сделают. А что тогда будут считать более слабые?
Ну это всё можно учесть в прайсе. На слабые машины ценник будет ниже. Поэтому каждый юзер сможет выбрать по своим предпочтениям: скорость или цена. В конце-концов, естественный отбор никто не отменял. Старой рухляди место на свалке (или в музее). Я конечно понимаю, что и современные процы сильно различаются в производительности между собой, но мы исходим из среднего. Если производительность агента в десятки раз ниже среднего, то нафиг нужен такой агент.
Ну либо нужно предусмотреть возможность остановить тормознутого агента прямо из программы и передать задачу более быстрому. Это удобно было бы делать в конце, когда 99% агентов давно отработали, а несколько "тормозов" портят всю малину.