Генетический алгоритм и его возможно применение - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я давно писал об этом, когда использовал фреймы в эксперте. Уже не помню точно сути, кажется у меня стали приходить не все фреймы (причём лучших результатов). Я поищу старые сообщения и попытаюсь уточнить.
Но точно помню, было чётко воспроизводимо в моём эксперте - как только количество переборов превышало некое кол-во и оно отображалось в научном виде, генетика у меня ломалась. Важно, что не просто было большое к-во шагов у переменной, а и количество переменных было большим.
Всё понятно.
Есть проблема с фреймами на "большой" генетике.
Будем исправлять.
Что значит "работает совершенно неправильно"?
Как можно воспроизвести неправильность работы?
https://www.mql5.com/ru/forum/321656/page17#comment_13569022
С фреймами я уже не проверю, отказался.
А с обычной генетикой проверил на последнем билде. Вот результат без "переполнения разрядности"
После прерывания:
С "переполнением":
После прохождения нескольких прерванных экспертом проходов (контроль правильности входных переменных), генетика остановилась навечно. После прерывания:
Ни одного реального результата.
Попробовал в качестве примера Advisors/MAPSARSizeOptimized.ex5, работает. Ясно, что проблема с "переполнением разрядности" и с фреймами воспроизводится только с моим экспертом, но как найти проблему... Там всё очень сложно, OnTradeTransaction и пр. Это я ещё фреймы убрал. Код показать не могу, да и гигантский он, под мегабайт. А урезать до воспроизводимого примера - безнадёжно долго. Если будет время, попробую убрать OnTradeTransaction, может ещё какие навороты.
Факт в том, что если не превышать количество проходов, всё отлично работает.
А фреймы отлично работали (без превышения) до билда 2286 включительно.
...
пока проблема одна - ГА может через некоторое время начать сходиться вокруг небольшой группы параметров оптимизации - по моему это нормально, все ГА так работают и это проблема их использования
...
сходимость к некоторому экстремуму - совершенно нормальное явление для любого алгоритма оптимизации, нет никаких предпосылок предполагать, что данный участок не_является/является глобальным или локальным.
другое дело, что в АО должен быть механизм, позволяющий усиливать процент мутаций (или иной эквивалент в логике, позволяющий усиливать расширение окрестностей поиска), при начале топтания на некотором участке, будет найден или нет экстремум лучше - неизвестно заранее, но то что искать пора в других местах это определенно точно нужно.
у АО, любых, нет проблем, есть проблема в другом - определении критерия оптимизации таким образом, что бы возможные плоскости в многомерном пространстве как можно меньше пересекались, это лежит в ответственности исследователя, к примеру, задали критерий макс баланс, этому критерию в абсолютном выражении может соответсвовать несколько или множество точек, но только некоторые из них представляют ценность на самом деле, то есть баланс 98756423 был достигнут при 1523 сделок при просадке 11% и такой же баланс был достигнут при 12 сделок но с просадкой 95%, какой вариант предпочтительнее? - таким образом представив критерий оптимизации так, что бы исключить пересечение плоскостей соответствующих векторов параметров можно не только облегчить и тем самым ускорить сходимость к глобальному экстремуму, но и получить однозначные варианты параметров торговой системы.
После прохождения нескольких прерванных экспертом проходов (контроль правильности входных переменных), генетика остановилась навечно. После прерывания:
Ни одного реального результата.
Вот не помню, писал ли где по этому поводу на форуме, но действительно это проблема и не понятно, почему так реализовано в МТ. По идее, если эксперт вернул код ошибки "неверные параметры", тестер обязан сгенерировать другой экземпляр взамен, чтобы популяция была полная.
Вот не помню, писал ли где по этому поводу на форуме, но действительно это проблема и не понятно, почему так реализовано в МТ. По идее, если эксперт вернул код ошибки "неверные параметры", тестер обязан сгенерировать другой экземпляр взамен, чтобы популяция была полная.
Если на все неправильные комбинации параметров возвращать INIT_PARAMETERS_INCORRECT, их получается слишком много, и поколение завершается с ошибкой. Поэтому я возвращаю INIT_PARAMETERS_INCORRECT только при неправильном конкретном параметре, если он выходит за пределы. А при неправильной комбинации (один параметр не должен превышать другой) я останавливаю проход, возвращаю INIT_SUCCEEDED и Custom = -N. Наверное, это портит генетику, но вариантов не вижу. Вернее есть вариант, избавляясь от неправильных комбинаций (в частном случае - делая один параметр дельтой к другому: v1=X, v2=Y+v1), но это слишком сильный мутаген. Два параметра будут жёстко связаны, и при изменении одного всё съезжает. Я ушёл от такого варианта в пользу фейкового результата вместо ошибки.
Если на все неправильные комбинации параметров возвращать INIT_PARAMETERS_INCORRECT, их получается слишком много, и поколение завершается с ошибкой. Поэтому я возвращаю INIT_PARAMETERS_INCORRECT только при неправильном конкретном параметре, если он выходит за пределы. А при неправильной комбинации (один параметр не должен превышать другой) я останавливаю проход, возвращаю INIT_SUCCEEDED и Custom = -N. Наверное, это портит генетику, но вариантов не вижу. Вернее есть вариант, избавляясь от неправильных комбинаций (в частном случае - делая один параметр дельтой к другому: v1=X, v2=Y+v1), но это слишком сильный мутаген. Два параметра будут жёстко связаны, и при изменении одного всё съезжает. Я ушёл от такого варианта в пользу фейкового результата вместо ошибки.
хороший вариант возвращать -DBL_MAX при недопустимом варианте, вместо ошибки.
вообще, мне удалось реализовать внешний га при сохранении всех прелестей мультивалютной потиковой достоверности тестера МТ, при этом есть возможность использовать все ядра процессоров и/или сетевых агентов, в том числе облачных, избегая при этом ситуаций когда агенты простаивают из за преждевременных завершений проходов или недоукомплектования популяций га.
есть информация, только ТССССС.... что в штатном оптимизаторе планируется реализация нескольких видов АО, и даже с параметрами, но это неточно.
хороший вариант возвращать -DBL_MAX при недопустимом варианте, вместо ошибки.
а если возвращать рендомное значение - это будет хуже для АО ?
а если возвращать рендомное значение - это будет хуже для АО ?
гораздо хуже.
если у нас цель - запудрить "моск" АО, то самый лучший способ это возвращать рандомное число.
хороший вариант возвращать -DBL_MAX при недопустимом варианте, вместо ошибки.
Это слишком много, график масштабируется так, что не разглядишь полезные результаты. Я возвращаю значение несколько большее, чем худший Custom. Главное же - задать правильное направление для улучшения.
а если возвращать рендомное значение - это будет хуже для АО ?
А смысл? Главное - правильное направление, значит надо показать GA, что здесь он показал худший результат, а не просто слабый.
Что значит "работает совершенно неправильно"?
Как можно воспроизвести неправильность работы?
Убрал OnTradeTransaction, не помогло. Буду думать дальше.