Об одном применении ООП - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
главное как это потом удобно юзать. Чтобы пробовать разные входы можно сделать это оптом по номеру сетапа входа. Т.е. есть коллекция сетапов входа. Если удобно, то как массив функций. Самые простые - безусловная покупка или продажа по рынку. Или условная)) А потом запускаем оптимизатор и перебираем разные сетапы входа
Да, как-то так пока видится, в настройках задаем номер стратегии, в оптимизаторе оптимизируем по номерам. Но это на первое время, давно есть мечта сделать самооптимизацию на лету.
какая цель у этой самооптимизации (целевая функция)?
Цель очевидная. Во первых, оптимизатор в тестере не хватает текущие сутки, по крайней мере в МТ4 точно. А я для МТ4 делаю.
Второе - рынок может резко меняться в течении дня, причем без всяких поводов(новостей). Сами наверное замечали, идет вялый флет ... флет, и вдруг всем как будто горчицей под хвостом намазали, котировки начинают рвать. Или идет размашистый флет, или вообще полный хаос.
Я думаю, можно классифицировать такие состояния и при их определении включать нужную модификацию стратегии. Как это сделать? Создать ИИ у меня кишка тонка. А вот методом оптимизации можно косвенно определить состояние.
Пока это лишь непроверенные мысли.
Да, как-то так пока видится, в настройках задаем номер стратегии, в оптимизаторе оптимизируем по номерам. Но это на первое время, давно есть мечта сделать самооптимизацию на лету.
Ваш клиент хочет завернуть все известные ему стратегии в одного эксперта, как я понимаю. Вы не сможете закончить эту задачу до конца, пока у Вас не появится список стратегий. Советую совместно составить ТЗ.
Если ПЛЮСОМ к этому списку стратегий затронули вопрос самооптимизации, тогда пишите ему нейронную сеть, не изобретайте велосипед и не морочьте клиенту знанием основ программирования голову. Это как раз то, что он от Вас просит.
А можно привести пример "зашиба"?
Вот пожалуйста. Иерархия торговых классов в стандартной библиотеке:
Из нее следует, что модуль управления капиталом - это эксперт. Трейлинг стоп - это тоже эксперт. Эксперт включает в себя другие эксперты. Такое противоречивое наследование получается из-за того, что и трейлингу и управлению капиталом требуется доступ к некоторым приватным данным и методам базового эксперта.
По мимо этого идут длинные гирлянды наследования. CIndicators использует CIndicatorBuffer, который в свою очередь вызывает свои вышестоящие методы. В итоге простая трасировка получения значения индикатора становится крайне запутанной задачай. После трех рекурсивных вызовов, полностью теряется понимание откуда что берется.
И это только один пример неудачного наследования. В действительности, любая более менее большая иерархия классов основанная на наследовании практически всегда становится противоречивой, запутанной и рекурсивной. Что крайне усложняет процесс отладки и дальнейшей разработки.
Видится, что глубину наследования необходимо ограничивать 1-2 уровнями. При том, первый уровень должен наследоваться от глобального и универсального определения нулевого уровня CObject (все - объект) и реализовывать конкретную сущность "Эксперт", "Индикатор", "Трейлинг стоп". Вторые уровни уже должны реализовывать конкретные реализации "Эксперт на основе MACD", "Индикатор SMA", "Скользящий трейлинг стоп" и т.д. А вот за использования третьего уровня нужно жестоко карать и всячески преследовать.
Т.е. получается, что классификация действительно ценный инструмент, только тогда, когда она:
Ваш клиент хочет завернуть все известные ему стратегии в одного эксперта, как я понимаю. Вы не сможете закончить эту задачу до конца, пока у Вас не появится список стратегий. Советую совместно составить ТЗ.
Если ПЛЮСОМ к этому списку стратегий затронули вопрос самооптимизации, тогда пишите ему нейронную сеть, не изобретайте велосипед и не морочьте клиенту знанием основ программирования голову. Это как раз то, что он от Вас просит.
Вот пожалуйста. Иерархия торговых классов в стандартной библиотеке:
Из нее следует, что модуль управления капиталом - это эксперт. Трейлинг стоп - это тоже эксперт. Эксперт включает в себя другие эксперты. Такое противоречивое наследование получается из-за того, что и трейлингу и управлению капиталом требуется доступ к некоторым приватным данным и методам базового эксперта.
По мимо этого идут длинные гирлянды наследования. CIndicators использует CIndicatorBuffer, который в свою очередь вызывает свои вышестоящие методы. В итоге простая трасировка получения значения индикатора становится крайне запутанной задачай. После трех рекурсивных вызовов, полностью теряется понимание откуда что берется.
И это только один пример неудачного наследования. В действительности, любая более менее большая иерархия классов основанная на наследовании практически всегда становится противоречивой, запутанной и рекурсивной. Что крайне усложняет процесс отладки и дальнейшей разработки.
Видится, что глубину наследования необходимо ограничивать 1-2 уровнями. При том, первый уровень должен наследоваться от глобального и универсального определения нулевого уровня CObject (все - объект) и реализовывать конкретную сущность "Эксперт", "Индикатор", "Трейлинг стоп". Вторые уровни уже должны реализовывать конкретные реализации "Эксперт на основе MACD", "Индикатор SMA", "Скользящий трейлинг стоп" и т.д. А вот за использования третьего уровня нужно жестоко карать и всячески преследовать.
Теперь мысль ясна. Кстати, у меня в роботах для себя именно так по простому и сделано, как я подчеркнул. Названия только другие.
ЗЫ: В чем такой граф составили? Что-то а-ля Doxygen?
Вот пожалуйста. Иерархия торговых классов в стандартной библиотеке:
Из нее следует, что модуль управления капиталом - это эксперт. Трейлинг стоп - это тоже эксперт. Эксперт включает в себя другие эксперты. Такое противоречивое наследование получается из-за того, что и трейлингу и управлению капиталом требуется доступ к некоторым приватным данным и методам базового эксперта.
По мимо этого идут длинные гирлянды наследования. CIndicators использует CIndicatorBuffer, который в свою очередь вызывает свои вышестоящие методы. В итоге простая трасировка получения значения индикатора становится крайне запутанной задачай. После трех рекурсивных вызовов, полностью теряется понимание откуда что берется.
И это только один пример неудачного наследования. В действительности, любая более менее большая иерархия классов основанная на наследовании практически всегда становится противоречивой, запутанной и рекурсивной. Что крайне усложняет процесс отладки и дальнейшей разработки.
Видится, что глубину наследования необходимо ограничивать 1-2 уровнями. При том, первый уровень должен наследоваться от глобального и универсального определения нулевого уровня CObject (все - объект) и реализовывать конкретную сущность "Эксперт", "Индикатор", "Трейлинг стоп". Вторые уровни уже должны реализовывать конкретные реализации "Эксперт на основе MACD", "Индикатор SMA", "Скользящий трейлинг стоп" и т.д. А вот за использования третьего уровня нужно жестоко карать и всячески преследовать.
Т.е. получается, что классификация действительно ценный инструмент, только тогда, когда она:
+ очень верные мысли.
ЗЫ: В чем такой граф составили? Что-то а-ля Doxygen?
Да, если бы;) Карпел над этим в SnagIt около часа. Специально создавал для своей статьи.