Обсуждение статьи "Параллельная оптимизация методом роя частиц (Particle Swarm Optimization)"
Оправдана ли проверка на уникальность и хранение базы параметров? Проводились ли замеры на предмет снижения скорости работы алгоритма?
В виду того, что как правило используется огромное пространство поиска при оптимизации и вероятность повторных вариантов крайне мала, а при небольших пространствах поиска и вовсе более рациональным является полный перебор.
ЗЫ Спасибо автору за почву для размышлений.
ЗЗЫ не совсем понял как решён вопрос "мягкого" загружения агентов при фиксированном размере колонии (или популяции) без простоев, пока перечитываю статью.
Статья показывает не проработанные моменты со стороны MT5. Например, получение без DLL значений неоптимизируемых параметров в OnTesterInit. И той же комиссии.
Было бы замечательно добавить в исходник возможность включения (через макрос) считывание всех параметров Тестера через DLL. Готовые решения есть.
Еще из пожеланий - генерация opt-файла из PSO-проходов.
Надо будет на практике сравнить это решение и штатный ГА по производительности и качеству. Для любой безындикаторной ТС несложно должно быть (на основе исходников из статьи, т.к. универсальный стиль).
Статья супер! Но далеко не для новичков.
Дочитал.
Слишком много кода для задачи замены штатного оптимизатора, слишком много инклюдников, кто в этом будет разбираться? - для подавляющего большинства читателей статья останется за гранью понимания, к сожалению.
Каким образом можно взять любой эксперт и с минимальными усилиями прикрутить к нему библиотеку PSO?
В идеале - алгоритм оптимизации должен быть совершенно отдельной сущностью, что бы в него не приходилось лазить каждый раз, как понадобиться писать новый советник (любой алгоритм, который планируется оптимизировать).
Кроме того, какие настройки алгоритма приемлемы в большинстве практических случаев? - на этот вопрос автор не дал ответа. И, если, пытливому уму читателя вздумается оптимизировать параметры алгоритма этим же алгоритмом, то прямо так с ходу это сделать не получится, поскольку код не обособлен.
Не сочтите, пожалуйста, за брюзжание, но готового к использованию инструмента, без ненужного для конкретных задач кода, нет.
Дочитал.
Слишком много кода для задачи замены штатного оптимизатора, слишком много инклюдников, кто в этом будет разбираться? - для подавляющего большинства читателей статья останется за гранью понимания, к сожалению.
Каким образом можно взять любой эксперт и с минимальными усилиями прикрутить к нему библиотеку PSO?
В идеале - алгоритм оптимизации должен быть совершенно отдельной сущностью, что бы в него не приходилось лазить каждый раз, как понадобиться писать новый советник (любой алгоритм, который планируется оптимизировать).
Кроме того, какие настройки алгоритма приемлемы в большинстве практических случаев? - на этот вопрос автор не дал ответа. И, если, пытливому уму читателя вздумается оптимизировать параметры алгоритма этим же алгоритмом, то прямо так с ходу это сделать не получится, поскольку код не обособлен.
Не сочтите, пожалуйста, за брюзжание, но готового к использованию инструмента, без ненужного для конкретных задач кода, нет.
Разумеется, нельзя объять необъятное. Представлена вторая итерация открытого инструмента (первая, нераспараллеленная была опубликована раньше в блоге). Он готов в том смысле, что за Вас уже придумали куда какой код прописывать и как это будет работать. Согласен, что пока нет продукта в коробке. Но он бы продавался в маркете. Здесь представлен набор "сделай сам" с готовой инструкцией.
Что касается инклудников - они добавлены не от хорошей жизни, а потому что нет аналогичных штатных способов сделать все то же самое (и нужное). И это очень хорошо, что все эти рутинные вещи уже есть готовые в виде инклудников, которые только и надо то подключить (за что большое спасибо fxsaber-у). Странно на сайте алго-трейдинга жаловаться на основной способ избежать дублирования работы. Если б этих инклудников не было, пришлось делать весь проект с нуля. И лучше инклудники, чем батники. В целом нет зависимостей от сторонних программ и DLL. И не может (какая-никакая) альтернатива встроенному методу оптимизации быть реализована малым кодом.
Что касается настройки парамеров PSO, то это открытая задача для любого метода оптимизации. В частности, для встроенного ГА есть некие жестко зашитые настройки, которые пользователи не могут менять, и потому многие именно на этот момент жалуются, и им приходится у Вас же заказывать кастом-решения на базе ГА. То есть получается, что отсутствие настроек плохо, а когда они есть - тоже плохо, потому что вы нам их дали и мы теперь не знаем, что с ними делать. А делать с ними вот что: исследования под каждую конкретную задачу. Просить готовые настройки для какого-то неизвестного черного ящика, которым является чей-то эксперт, это все равно что для самого этого эксперта сразу (без оптимизации) просить идеальные параметры. А зачем нам тогда сама оптимизация понадобилась? Потому что это не все так просто - ни поиск параметров эксперта, ни поиск мета-параметров конкретного алгоритма оптимизации. То что Вы спрашиваете - это все равно что попросить уже готовую конфигурацию нейросети для данных, которых никто еще не видел. Не бывает оптимальных настроек для большинства экспертов == практических случаев.
В качестве отправной точки можно брать проведенную в статье параллель с ГА: если пользователь запускал ГА 1000 раз, пусть поставит счетчик групп 1000, если в ГА было 100 поколений - пусть будет 100 циклов PSO, и если в популяции было 100 особей, пусть размер роя будет тоже 100.
Что касается инклудников - они добавлены не от хорошей жизни, а потому что нет аналогичных штатных способов сделать все то же самое (и нужное). И это очень хорошо, что все эти рутинные вещи уже есть готовые в виде инклудников, которые только и надо то подключить (за что большое спасибо fxsaber-у). Странно на сайте алго-трейдинга жаловаться на основной способ избежать дублирования работы. Если б этих инклудников не было, пришлось делать весь проект с нуля. И лучше инклудники, чем батники. В целом нет зависимостей от сторонних программ и DLL. И не может (какая-никакая) альтернатива встроенному методу оптимизации быть реализована малым кодом.
дублировать функционал штатного тестера в виде виртуальных торговых функций не имеет смысла (я по крайней мере не вижу смысла, эту работу уже проделали за нас смекалистые высокооплачиваемые ребята из MQ), а вот сделать дополнение, расширение функциональности - вполне да.
выделенное жирном - может, в самом деле.
Что касается настройки парамеров PSO, то это открытая задача для любого метода оптимизации. В частности, для встроенного ГА есть некие жестко зашитые настройки, которые пользователи не могут менять, и потому многие именно на этот момент жалуются, и им приходится у Вас же заказывать кастом-решения на базе ГА. То есть получается, что отсутствие настроек плохо, а когда они есть - тоже плохо, потому что вы нам их дали и мы теперь не знаем, что с ними делать. А делать с ними вот что: исследования под каждую конкретную задачу. Просить готовые настройки для какого-то неизвестного черного ящика, которым является чей-то эксперт, это все равно что для самого этого эксперта сразу (без оптимизации) просить идеальные параметры. А зачем нам тогда сама оптимизация понадобилась? Потому что это не все так просто - ни поиск параметров эксперта, ни поиск мета-параметров конкретного алгоритма оптимизации. То что Вы спрашиваете - это все равно что попросить уже готовую конфигурацию нейросети для данных, которых никто еще не видел. Не бывает оптимальных настроек для большинства экспертов == практических случаев.
В качестве отправной точки можно брать проведенную в статье параллель с ГА: если пользователь запускал ГА 1000 раз, пусть поставит счетчик групп 1000, если в ГА было 100 поколений - пусть будет 100 циклов PSO, и если в популяции было 100 особей, пусть размер роя будет тоже 100.
вышесказанное Вами говорит о том, что работа по исследованию поисковых способностей алгоритма не была проделана. готовая нейронная сеть и алгоритм оптимизации - это не одно и тоже, НС требует обучения на конкретных данных и зависит от чистоты данных, полноты и актуальности, а вот алгоритм оптимизации никаким образом не должен зависеть от этих факторов, ему должно быть пофиг, обучать ли нейронную сеть (оптимизировать), или найти оптимальные параметры самого себя на наборе тестовых задач.
Но! В любом случае, мои замечания по статье носят сугубо практический характер, но не принципиальный. Любые точки зрения на проблематику оптимизации имеют право на существование. Вы видите это так, я вижу это несколько иначе, что есть хорошо.
В современном мире никому не нужны конструкторы "собери сам", всем нужны готовые решения, мерседесы и прочие ауди покупают не чтобы доделывать, а чтобы наслаждаться... или по крайней мере должен быть представлен малокровный способ прикрутить решение к уже имеющимся проектам заказчика.
;)
интересная статья
не понравилась реализация - связка виртуальной торговли с тестером,
возможно это работает как задумано, но имхо, реализация для оптимизации должна была быть или полностью с помощью виртуальной торговли ( Virtual.mqh ) - тогда это будет автооптимизация онлайн,
или нужна реализация используя возможности тестера стратегий терминала (OnTesterInit()) - получили бы альтернативный ГА для тестера, в текущей реализации сложно предположить как работает тестер стратегий
спасибо за интересный материал и программную реализацию, может пригодится
Отвечу по порядку.
Запоминание хэшей просчитанных комбинаций опционально - это можно исключить из исходника при желании. Наличие этой проверки не должно сильно тормозить процесс по сравнению со скоростью обсчета самой торговли.
Полный перебор параметров имеет смысл только для действительно малых пространствах, но между ними и миллионами комбинаций существует целый пласт юзкейсов. Например, нужно прогнать оптимизацию по 10000 комбинаций, полный перебор займет 1 час, а хочется увидеть приблизительную оценку уже через несколько минут. В этом случае явно требуется быстрый способ оптимизации, и при этом дубликаты комбинаций очень вероятны. А за счет их детекции удается ускорить обработку.
Загрузка агентов оставлена в ведении тестера. Торговые проходы в среднем распределяются равномерно (количество равное, а сложность усреднена за счет рандомизации).
Прикручивание opt-файлов напрашивается, но до всего сразу руки не доходят. Если прикручивать все опции, то результат никогда не увидит свет.
Использовать DLL и внешние программы не хотелось бы, так сказать, by design.
Использование виртуальных торговых функций имеет огромный смысл - они выполняются гораздо быстрее встроенных. Это во-первых. Во-вторых, именно они позволяют менять параметры многократно в цикле внутри одного прохода (внутри группы PSO). Если бы не это, то каждый отдельный проход нужно было бы синхронизировать с группой (ставшей по отношению к программе внешней сущностью ) - а это пока что возможно, опять таки, либо через внешние программы, либо через разделяемые файлы. И тут были бы новые супер-тормоза. Но наконец в-третьих, и это самое главное. При эксплуатации обычных проходов тестера без виртуализации невозможно прикрутить свой собственный алгоритм оптимизации, чтобы он жил внутри MQL. Попробуйте подумать, как бы Вы это сделали. Такое возможно только с помощью внешних программ и/или батников. У fxsaber-а есть даже подходящие "автоматизаторы", но это означает внешний контроль за запуском процессов и сборкой их результатов. Это тормоза в квадрате, плюс совершенно неудобно в пользовании. Разбираться с этими внешними контроллерами требует гораздо большей квалификации.
По поводу утверждения о малом коде для реализации замены штатного оптимизатора - позволю себе не согласиться. Насколько я знаю, альтернативные работы тоже не маленькие, и требуют адаптации кода экспертов. Если есть конкретная демонстрация на обособленный алгоритм оптимизации с малым кодом и очень простым подключением в эксперт, поделитесь с общественностью. ;-)
По поводу пофигизма алгоритма оптимизации, будто он без настройки должен справляться с любой задачей, - не согласен. Это была бы какая-то магия, "серебряная пуля".
Не вижу принципиальной разницы между алгоритмом оптимизации и алгоритмом НС. И там, и там есть мета-параметры.
И да - " работа по исследованию поисковых способностей алгоритма не была проделана ", потому что нельзя объять необъятное - и так работы было выше крыши. Цель публикации как раз в том, чтобы за счет общедоступности предоставить желающим возможность провести исследования и поделиться находками.
Автооптимизация онлайн есть (было опубликовано в блоге), но она идет только в одном потоке, а смысл статьи был в распараллеливании алгоритма. Использование тестера в качестве итератора заданий и их раздачи по агентам для группового виртуального обсчета -- это самая главная фишка всего проекта. Синергия.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Параллельная оптимизация методом роя частиц (Particle Swarm Optimization):
В статье описан способ быстрой оптимизиции методом роя частиц, представлена его реализация на MQL, готовая к применению как в однопоточном режиме внутри эксперта, так и в параллельном многопоточном режиме в качестве надстройки, выполняющейся на локальных агентах тестера.
С алгоритмической точки зрения метод PSO относительно прост. Основная идея состоит в том, чтобы сгенерировать множество виртуальных "частиц" в пространстве входных параметров советника. Затем частицы двигаются и меняют свою скорость в зависимости от показателей торговли советника в соответствующих точках пространства. Процесс повторяется много раз, пока показатели не перестают улучшаться. Псевдо-код алгоритма приведен ниже:
Particle Swarm Optimization Pseudo-Code
Согласно нему каждая частица обладает текущей позицией, скоростью и памятью о своей "лучшей" точке в прошлом. Под "лучшей" имеется в виду точка (набор входных параметров эксперта), где достигалось наибольшее значение целевой функции для этой частицы. Опишем это в классе.
Размер всех массивов равен размерности пространства оптимизации, то есть количеству оптимизируемых параметров эксперта (передается в конструктор). Поскольку оптимизация по умолчанию предполагает, что чем больше значение целевой функции, тем оно лучше, мы инициализируем поле bestValue минимальным возможным числом -DBL_MAX. В качестве критерия оценки эксперта обычно выступает один из показателей торговли: прибыль, прибыльность, коэффициент Шарпа и т.д. Если требуется оптимизация по величине,которая становится лучше при уменьшении, например, просадка, это легко обеспечить эквивалентными преобразованиями для максимизации обратных величин.
Массивы и переменные сделаны публичными для упрощения доступа и кода их пересчета. Строгое следование принципам ООП потребовало бы скрыть их с помощью модификатора private и описать методы для чтения и модификации.
Автор: Stanislav Korotky