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