Об одном применении ООП - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Гыыы - интеловский компилятор, который рвет всех, как тузик грелку, будет догонять интерпретатор?
Саныч, вы много не пейте )))
Читаем внимательно пост:
Ваши классы для матриц должны будут использовать интеловскую библиотеку для матричных операций,
Это БИБЛИОТЕКА!
Отсюда расширяем кругозор. Чтоб не утруждать, привожу:
Intel® Math Kernel Library (Intel® MKL) accelerates math processing routines that increase application performance and reduce development time. Intel® MKL includes highly vectorized and threaded Linear Algebra, Fast Fourier Transforms (FFT), Vector Math and Statistics functions.
Гыыы... Гыыы....
Под интерпретатором имелся в виду ваш любимый R
В R интерпретируется всего ничего. Весь функционал - нативный код. Вызываем функцию, и интерпретируется только сама команда. И все.
А скорость выполнения встроенных функций просто великолепна. Руками, да на МКЛ такого не напишешь. Или оч долго, да и не нужно.
Это не ко мне. Я вполне верю что векторные и матричные операции там на уровне. Если бы нет, он бы не был в топ-5.
И к самому языку я отношусь хорошо. Но сравнение MQL и R просто смехотворно )
прикладной торговый язык против языка для анализа данных? как их можно вообще сравнивать?
Выгрузил данные (MQL) проанализировал (R) нашел эдж, написал АТС (MQL), если надо, со связкой к нужному функционалу аналитической платформы.
Хочешь маркет -- портируй нужный функционал, это вполне честно. Тем более возможная помощь есть в виде портированной разработчиками alglib
В идеале можно запустить целую экосистему советников с тем, чтобы смоделировать как они выживают и изменяются на основе ГА, чтобы лучше просоответствовать историческим котировкам.
Типа вначале были простейшие, которые покупали или продавали по одному простому условию. Затем, стали образовываться более сложные на основе простых. В общем, вымирание и появление новых эффективных экспертов отслеживать))) Типа эволюционного программирования на основе булевского скрещивания других особей
В идеале можно запустить целую экосистему советников с тем, чтобы смоделировать как они выживают и изменяются на основе ГА, чтобы лучше просоответствовать историческим котировкам.
Типа вначале были простейшие, которые покупали или продавали по одному простому условию. Затем, стали образовываться более сложные на основе простых. В общем, вымирание и появление новых эффективных экспертов отслеживать))) Типа эволюционного программирования на основе булевского скрещивания других особей
про эволюцию и "вымирание": одна небезивестная компания устраивала конкурс на программирование AI. Всё по взрослому - модель хищник-жертва, экология, география, размножение, возможность коммуникаций между экземплярами и прочее прочее. Из всех навороченнейших AI по результатам множества прогонов выиграл простейший алгоритм поведения особи: жрать всё до чего можно дотянуться, размножаться при первой возможности, если вдруг что то бежать вместе со стадом.
про эволюцию и "вымирание": одна небезивестная компания устраивала конкурс на программирование AI. Всё по взрослому - модель хищник-жертва, экология, география, размножение, возможность коммуникаций между экземплярами и прочее прочее. Из всех навороченнейших AI по результатам множества прогонов выиграл простейший алгоритм поведения особи: жрать всё до чего можно дотянуться, размножаться при первой возможности, если вдруг что то бежать вместе со стадом.
MS это устраивала в начале 2000-х для попуряризации C#. А до этого игра была популярна на Java.
Но MS все это обернула в призы, я выиграл како-то этап, уже и не помню какой. Но стратегия была Крыса в засаде)))))
Помню другое, звонит в дверь почтальон, - вам посылка от MS.
Пришел на почту - такая коробка на 20 кг, вся забита книжками по программированию))
Ваш пост имел бы ЛОГИЧЕСКОЕ завершение, если бы в подтверждение своих рассуждений о противоречивости наследования, привели бы графическую схему своего видения иерархии классов. Для наглядности! :)
Ваш пост имел бы ЛОГИЧЕСКОЕ завершение, если бы в подтверждение своих рассуждений о противоречивости наследования, привели бы графическую схему своего видения иерархии классов. Для наглядности! :)
Пока на уровне тезисов:
Серебренной пули нет ("No Silver Bullet" Фредерик Брукс, 1986). Т.е. нет какой-то универсальной технологии правильной разработки ПО. Любой метод проектирования может порождать противоречивость, сложность восприятия и как следствие замедление или даже невозможность дальнейшей разработки.Наследование непротиворечиво по своей сути. Однако используя его очень просто создать противоречивую конструкцию, гораздо проще, чем может показаться вначале проектирования.
Интерфейсы и включения более безопасны.
Из сказанного видится, что как правило лучше использовать плоские модели: ограниченная цепочка наследования из двух, максимум трех уровней и взаимообмен через интерфейсы, функционал которых лучше реализуется с помощью включений.
К сожалению, интерфейсы в MQL5 запрещены, и это очень печально, хотя их можно было бы включить изящным ходом: разрешить множественной наследование чисто абстрактных классов.
З.Ы. Будет время начерчю дерево классов своего проекта CStrategy. Самому интересно будет сравнить. Хотя еще раз подчеркну: серебренной пули нет, т.е. не в коем случае не рассматривать тот же CStrategy по принципу "смотрите, как надо делать".
Не умеешь кошек готовить, молчи...
R. Этот язык для статистического анализа данных также имеет 2 системы объектно-ориентированного программирования
Ну и что? Там еще много чего есть такого, чего нет в MQL. Ну и что?
Речь ведь не об этом. Алгоритмическое превосходство одного языка над другим вообще не имеет значения после некоторого порога возможностей по отношению к предметной области.
Жуете здесь кодеровскую вкусовщину, а лично я здесь ради торговли.
ПС.
Ваши классы для матриц должны будут использовать интеловскую библиотеку для матричных операций, вот тогда Вы, быть может, сравняетесь с R в этом вопросе.
Вы свои матрицы в каждый свой пост суете. В реальной торговле их применение очень ограничено. 99.9% экспертов не используют матричных рассчетов (не путать с массивами в MQL).
R создавался для быстрого анализа данных, но не для проведения полноценной симуляции. А что Вы скажите на счет расчетов в скользящем окне? 99.99% процентов всех расчетов в трейдинге сделаны именно на скользящем окне. Т.е. если в матрицу Вы засовываете новый элемент, а старый убираете, после чего делаете пересчет, то стоимость этой операции должна быть O(1), и никак иначе. В MQL это можно сделать гарантированно практически во всех случаях, в вот как это сделать в R?