Машинное обучение в трейдинге: теория, модели, практика и алготорговля - страница 297
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
apply(embed(pattern, length(signal)), 1, cor, y = signal, method = 'pearson')
Спасибо! Интересно, сколько считает R такое. Замерял алгоритм библы при длине сигнала 1 000 000 и паттерна 100 000 - 1 секунда.
В миллион раз быстрее! Ну, и что? Торговые системы меряем как процессоры?
В миллион раз быстрее! Ну, и что? Торговые системы меряем как процессоры?
У вас комплекс какой-то.
Нет,не комплекс.
мкл и R совершенно разные и не пересекающиеся системы. И что сравнивать? Причем не Вы один!
мкл и R совершенно разные и не пересекающиеся системы. И что сравнивать? Причем не Вы один!
Меня интересовала только скорость реализации не редкой стат. задачи на любом из языков.
R - самый популярный стат. язык и здесь многие им владеют. Поэтому вопрос сравнения задан именно здесь.
Интересен сам алгоритм реализации и, соответственно, его эффективность. А на каком языке - не важно.
Меня интересовала только скорость реализации не редкой стат. задачи на любом из языков.
R - самый популярный стат. язык и здесь многие им владеют. Поэтому вопрос сравнения задан именно здесь.
Интересен сам алгоритм реализации и, соответственно, его эффективность. А на каком языке - не важно.
МТ - это торговый терминал. В соответствии с этим я, здесь на сайте, и в этой ветке обсуждаю разработку ТС. Но постоянно находятся люди, которые обсуждают какие-либо программерские штучки, которые практически никакого влияния не оказывают на результаты торговли. Ваш вопрос как раз из этой оперы, так как сама по себе корреляционная функция имеет смысл в составе других алгоритмов.
Эта функция может использоваться в блоках принятия торговых решений (во всяком случае я ее использую), но скорость ее исполнения не играет никакой роли, так как основное время на вычисление торгового сигнала определяется другими, вычислительно сложными алгоритмами, которых вообще нет на мкл.
Это на этапе исполнения.
Если рассмотреть этап разработки ТС, то R принципиально превосходит в скорости мкл, так как является интерпретатором, что крайне удобно на этапе, когда алгоритм не совсем понятен и надо попробовать много вариантов, например, сравнить корреляцию валютных пар. На R время проверки корреляции - это время стука по клаве, причем пара строк, включая очень удобное формирование исходных векторов.
Именно такой смысл я вкладывал, что не имеет никакого смысла сравнивать скорость исполнения этих функций и вообще любых других функций, реализованных на мкл и R.
ПС.
А вот Ваша библиотека избавила меня от необходимости изучать мкл5, за что спасибо.
МТ - это торговый терминал. В соответствии с этим я, здесь на сайте, и в этой ветке обсуждаю разработку ТС. Но постоянно находятся люди, которые обсуждают какие-либо программерские штучки, которые практически никакого влияния не оказывают на результаты торговли. Ваш вопрос как раз из этой оперы, так как сама по себе корреляционная функция имеет смысл в составе других алгоритмов.
Раньше некоторые идеи ТС не мог проверить, т.к. упирался в низкую производительность некоторых алгоритмов. В данном случае именно так и произошло - альтернативный алгоритм позволил в оптимизаторе исследовать старую, как мир, идею, но не могущую ранее быть посчитанной за разумное время.
Когда нужно посчитать сотни миллиардов КК Пирсона при паттернах длинной в несколько тысяч, то низкая скорость казалось бы простой задачи становится непреодолимым узким горлышком. Можно начать говорить, что если задача видится слишком тяжелой с вычислительной точки зрения, то это плохо сформулированная задача со слабым пониманием. Возможно, и так. Но что сделано, то сделано. А посмотреть, как реализуют подобное другие - всегда интересно.
Что лучше, потратить немного больше времени на разработку, но потом всегда быстро считать, или быстро разработать и потом всегда мирится с тормознутостью расчетов?
Если в R быстро разрабатывать но медленно считать, то где тогда считать? Побыстрому разработать суперкар который медленно ездит? Нахрен нужен такой суперкар.
Меня интересовала только скорость реализации не редкой стат. задачи на любом из языков.
R - самый популярный стат. язык и здесь многие им владеют. Поэтому вопрос сравнения задан именно здесь.
Интересен сам алгоритм реализации и, соответственно, его эффективность. А на каком языке - не важно.
Что-ж, на сигнале длины 1000000 и паттерне длины 100000 та реализация вообще вряд ли сосчитается в разумное время, т.к. потребует создания временной матрицы размером 900001x100000 :D Зато на её написание ушло меньше 30 секунд и до какого-то размера задач она будет вполне применима. Можно реализовать всё то же самое через fft/convolve, в этом случае потребуется написать больше кода, но скорость работы будет не сильно уступать сишному коду.
На R очень удобно делать прототипы сложных моделей - это и есть его сильная сторона. Быстродействие кода - вопрос навыков и опыта:
1. Некоторые конструкции и типы данных R работают быстрее других (mutable vs immutable types (list vs environment), for vs lapply/sapply/etc., S4 vs R6).
2. Легкость распараллеливания в R для некоторых задач позволяет получить решение медленным кодом быстрее, чем уйдет времени на написание быстрого кода на другом языке + вычисления.
3. Отдельные операции в языке сделаны универсально, но неэффективно. Если реализовывать мелкие, но вычислительно тяжелые функции на C++ - можно добиться потрясающих результатов, не сильно снижая скорость разработки, как в случае написания всего кода на C-подобном языке. Например, суммирование элементов матрицы по строкам или по столбцам в R можно сделать от 4 до 15 раз быстрее, чем это делают rowSums/colSums/apply(, 1, sum)/apply(, 2, sum).
Что-ж, на сигнале длины 1000000 и паттерне длины 100000 та реализация вообще вряд ли сосчитается в разумное время, т.к. потребует создания временной матрицы размером 900001x100000 :D Зато на её написание ушло меньше 30 секунд и до какого-то размера задач она будет вполне применима. Можно реализовать всё то же самое через fft/convolve, в этом случае потребуется написать больше кода, но скорость работы будет не сильно уступать сишному коду.
На R очень удобно делать прототипы сложных моделей - это и есть его сильная сторона. Быстродействие кода - вопрос навыков и опыта:
1. Некоторые конструкции и типы данных R работают быстрее других (mutable vs immutable types (list vs environment), for vs lapply/sapply/etc., S4 vs R6).
2. Легкость распараллеливания в R для некоторых задач позволяет получить решение медленным кодом быстрее, чем уйдет времени на написание быстрого кода на другом языке + вычисления.
3. Отдельные операции в языке сделаны универсально, но неэффективно. Если реализовывать мелкие, но вычислительно тяжелые функции на C++ - можно добиться потрясающих результатов, не сильно снижая скорость разработки, как в случае написания всего кода на C-подобном языке. Например, суммирование элементов матрицы по строкам или по столбцам в R можно сделать от 4 до 15 раз быстрее, чем это делают rowSums/colSums/apply(, 1, sum)/apply(, 2, sum).