Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
На сленге это называется пакетированием. Когда на агент посылается не один вариант ТС, а искусственно составленный пакет ТС, где оптимизируются только те параметры, которые вызывают быстрый перебор.
Грубо говоря, перед стандартной оптимизацией должно происходить следующее
На сленге это называется пакетированием. Когда на агент посылается не один вариант ТС, а искусственно составленный пакет ТС, где оптимизируются только те параметры, которые вызывают быстрый перебор.
Грубо говоря, перед стандартной оптимизацией должно происходить следующее
Стесняюсь спросить... Вы уже пробовали так делать? Потому что уже первый пункт (последующие пункты я понял ещё меньше) лично у меня вызывает массу вопросов.
К примеру, такие вопросы по первому пункту:
a. почему отдельные оптимизации одного параметра будут быстрее/медленнее чем оптимизация других параметров?
b. при прочих равных состояниях индикаторов и прочих расчетных методов в советнике на скорость прогона в тестере существенное влияние оказывает количество сделок на истории. по этому показателю можно судить лишь о влиянии каждого из параметров на количество сделок, но разное сочетание параметров могут давать разное количество сделок, поэтому фактор торможения тестера при единичной оптимизации параметра по количеству сделок становится не очевидным.
с. если провели предварительную оптимизацию каждого из параметров, то почему не делали полную оптимизацию всех параметров сразу, ведь это заняло бы тоже время.
d....
Стесняюсь спросить... Вы уже пробовали так делать?
На практике реализовывал, но это никогда не было универсально - задачи такой не ставил, т.к. ни к чему. Но когда решал для себя, получал ускорение на несколько порядков во время оптимизации.
Никто бездумно в своем коде не делает, например, три вложенных for от балды. Всегда стараются самый внешний for отдать наиболее тяжелому по влиянию на расчеты параметру, а самый внутренний цикл - самому легкому. Это я не говоря про оптимизацию, а про рациональное написание своих программ.
Точно такой же подход может быть реализован и при оптимизациях. Потому как оптимизация - это, фактически, вложенные циклы for.
1. Ответил же
2. Точно такой же подход может быть реализован и при оптимизациях. Потому как оптимизация - это, фактически, вложенные циклы for.
1. Не на все вопросы.
2. Оптимизация - это даже близко не лежит по смыслу и по целям циклам. Поскольку искомый вариант среди всех параметров может оказаться за пределами составленных циклов (ведь сумма всех циклов по количеству меньше количества всех вариантов, иначе бы в этом не было смысла).
Оптимизация - это даже близко не лежит по смыслу и по целям циклам. Поскольку искомый вариант среди всех параметров может оказаться за пределами составленных циклов (ведь сумма всех циклов по количеству меньше количества всех вариантов, иначе бы в этом не было смысла).
Не надо путать первый пост и то, что написал после на просьбу озвучить некоторые мысли.
Как раз конструкция for-for-for-.... в сумме и дает РОВНО столько, сколько выдает оптимизатор. Там экономия получается на буферировании. Точно так же, как происходит при написании собственных программ во время вложенных циклов.
Не надо путать первый пост и то, что написал после на просьбу озвучить некоторые мысли.
Как раз конструкция for-for-for-.... в сумме и дает РОВНО столько, сколько выдает оптимизатор. Там экономия получается на буферировании. Точно так же, как происходит при написании собственных программ во время вложенных циклов.
На примере будет проще. Чтобы понять, на каком интервале суток советник лучше всего показывает, можно пойти двумя путями
Только со временем торговли так можно поступить. С чем еще?
В данном случае временной интервал - это фильтр торговли. Поэтому именно так, как в примере, можно поступить с любым фильтром.
Каким образом? В каком примере?
Со временем достаточно одного прохода в тестере, потом можно проанализировать отчет. Если какой-то параметр типа периода индикатора или величины столопсса, для каждого значения надо проводить тестирование. Поэтому никак не сделать так же как со временем.
Стесняюсь спросить... Вы уже пробовали так делать? Потому что уже первый пункт (последующие пункты я понял ещё меньше) лично у меня вызывает массу вопросов.
К примеру, такие вопросы по первому пункту:
a. почему отдельные оптимизации одного параметра будут быстрее/медленнее чем оптимизация других параметров?
b. при прочих равных состояниях индикаторов и прочих расчетных методов в советнике на скорость прогона в тестере существенное влияние оказывает количество сделок на истории. по этому показателю можно судить лишь о влиянии каждого из параметров на количество сделок, но разное сочетание параметров могут давать разное количество сделок, поэтому фактор торможения тестера при единичной оптимизации параметра по количеству сделок становится не очевидным.
с. если провели предварительную оптимизацию каждого из параметров, то почему не делали полную оптимизацию всех параметров сразу, ведь это заняло бы тоже время.
d....
Подписываюсь под каждым словом.
ИМХО, исходный посыл содержит ошибку.
Единственный способ ускорить оптимизацию - это делать её сперва с большим шагом изменения параметров и постепенно его уменьшать до желаемого окончательного. Нечто вроде метода имитации отжига. Но насколько я понимаю, ГА примерно то же самое и делает, только называя сие хромосомами.