Машинное обучение в трейдинге: теория, модели, практика и алготорговля - страница 298
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Что лучше, потратить немного больше времени на разработку, но потом всегда быстро считать, или быстро разработать и потом всегда мирится с тормознутостью расчетов?
Если в R быстро разрабатывать но медленно считать, то где тогда считать? Побыстрому разработать суперкар который медленно ездит? Нахрен нужен такой суперкар.
В исследовательских задачах на первый план выходит именно скорость разработки. Вместо человека, который пишет супер-быстрый код, но проверяет 1 гипотезу в день, на работу запросто возьмут человека, который пишет медленный код и запускает расчёты на всю ночь, но к следующему дню у него оказываются проверены 20 гипотез.
Для production-реализации модели проще взять ещё одного человека на небольшую зарплату, который будет переписывать на быстродействующем языке наиболее перспективные модели. Программистов-то много, конкуренция высокая; а вот исследователей, способных придумать что-то новое, надо ещё поискать :P
Это обычная практика. Поищите вакансии quantitative researcher и quantitative developer. От первых обычно требуют знания R/Python, от вторых - C++/Java.
В исследовательских задачах на первый план выходит именно скорость разработки. Вместо человека, который пишет супер-быстрый код, но проверяет 1 гипотезу в день, на работу запросто возьмут человека, который пишет медленный код и запускает расчёты на всю ночь, но к следующему дню у него оказываются проверены 20 гипотез.
Для production-реализации модели проще взять ещё одного человека на небольшую зарплату, который будет переписывать на быстродействующем языке наиболее перспективные модели. Программистов-то много, конкуренция высокая; а вот исследователей, способных придумать что-то новое, надо ещё поискать :P
Это обычная практика. Поищите вакансии quantitative researcher и quantitative developer. От первых обычно требуют знания R/Python, от вторых - C++/Java.
А не проще ли пользоваться готовыми и быстрыми библиотеками с++? вместо того, что бы пользоваться тем же, но медленным в R при "быстрой разработке"? Вы, да и многие другие тут, постоянно делаете подмену понятий. Точно так же можно "быстро разрабатывать" и в C-подобной среде. Или что бы работать в R не нужны соответствующие познания в датамайнинг и статистике? Точно так же нужны знания и при разработке на С. Так зачем делать двойную работу?
И я не знаю про какую такую "обычную практику" Вы говорите, а я привык делать сразу хорошо и один раз.
Я за свою инженерную практику часто видел людей, которые почему то думали, что если они будут использовать супер-пупер удобные в разработке программные комплексы, то у них будет обязательно получаться всё хорошо... Но они не могли понять одного - что бы всё получалось хорошо нужно другое: сало в голове.
А не проще ли пользоваться готовыми и быстрыми библиотеками с++? вместо того, что бы пользоваться тем же, но медленным в R при "быстрой разработке"? Вы, да и многие другие тут, постоянно делаете подмену понятий. Точно так же можно "быстро разрабатывать" и в C-подобной среде.
Выбор языка - ваше право и личное дело. Насчёт библиотек - увы, для сколь-нибудь современных или необычных алгоритмов, реализовывать придется всё самостоятельно. Скажем, для расчёта "bipower variance" (что бы это значило? :D) я библиотек не нашел.
Или что бы работать в R не нужны соответствующие познания в датамайнинг и статистике?
Не утверждал такого и не поддерживаю это мнение.
И я не знаю про какую такую "обычную практику" Вы говорите, а я привык делать сразу хорошо и один раз.
Я за свою инженерную практику часто видел людей, которые почему то думали, что если они будут использовать супер-пупер удобные в разработке программные комплексы, то у них будет обязательно получаться всё хорошо... Но они не могли понять одного - что бы всё получалось хорошо нужно другое: сало в голове.
Моя практика в неких проектах со сложностью ## человеко-лет, где 95% кода написано на R, показывает, что для разных задач хороши разные инструменты, иногда даже медленные, если они используются для прототипов, а не для продакшена. В индустрии quantitative finance использование разных инструментов на разных этапах разработки - обычная практика, которая подтверждается требованиями к специалистам на разные вакансии. Упомянутые мною проекты стали бы сложнее на порядок, если бы они сразу реализовывались на C-подобном языке, даже универсальными солдатами, которые знают и умеют всё и сразу пишут решение задачи, без какого-либо этапа исследований.
За сим откланяюсь.
А не проще ли пользоваться готовыми и быстрыми библиотеками с++? вместо того, что бы пользоваться тем же, но медленным в R при "быстрой разработке"?
Когда обсуждается R я всегда стоял на комплексной, системной оценке этой "системы графики и статистики". сам алгоритмический язык вообще не упоминается в названии.
Лобовой сравнение быстродействия кода на R и как выше кода на мкл, или другом языке программирования, на конкретном, локальном примере совершенно НЕ корректно, так как ТС никогда не состоит как обсуждалось выше из функции корреляции, а всегда это большой набор, состоящий из кода и обращения к функциям. Так как R имеет огромный набор функций, то обычно код имеет небольшое число строк (1000 строк - это много), но очень емких содержательно.
Саму программу, которая решает некую содержательную проблему, можно грубо разбить на две части:
По п.1 если пришлось написать значительные объемы кода, то вопрос быстродействия может быть очень серьезным. Имеется три пути преодоления:
По п.2 в смысле быстродействия дело обстоит совершенно иначе и я сомневаюсь, чтобы без специальных усилий при обыденной разработке мкл-программы удастся по быстродействию превзойти R.
Например.
На поверхности лежит то, что в R операции над векторами и матрицами являются базовыми. Выражение вида a <- b*c исполняется библиотекой Intel. Циклов нет. Это доступно всем, каких-либо дополнительных знаний или усилий не требуется. При разработке мкл-программы скорее всего будут использованы циклы, хотя также имеется возможность обратится к этой же библиотеке (если программа не для маркета), но требуются достаточно высокого уровня знания и усилия для достижения одинакового результата.
Но это не все.
Если мы обращаемся к вычислительно тяжелым алгоритмам, а это обращения к функциям R, то сам разработчик, столкнувшись с проблемой быстродействия, озаботился этой проблемой и обычно решил проблему на этапе разработки. Обычно это решается либо написанием сишного кода, либо обращением к библиотекам на С или Фортране. Кроме этого, в таких алгоритмах среди параметров обращения имеется возможность указания использования многих ядер. Все это разработчик на R получает автоматически, не прилагаю усилий. Можно полностью сосредоточиться над сутью ТС, а не над техникой реализации. Сомнительно, чтобы разработчик мкл-программы сможет превзойти разработчика функций на R по банальной причине - надо специально работать над быстродействием, а не над сутью ТС.
Из всего написанного следует, что корректным сравнением быстродействия было бы на писание реального кода ТС на мкл и такого же кода на мкл+R (в R нет торговых приказов) и сравнить. Но во всей красе - а оно нам надо?
Кто нибудь пробовал работать с recurrence plots? почитать можно тут https://habrahabr.ru/post/145805/ , в частности подсовывать МО вместо сырых ВР? как вариант может сойдет
и еще на почитать http://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf
Идея для тех, кто может это реализовать. Сравнивать машинным зрением эти recurrent plots в поисках совпадений паттернов. Как замена беспонтовой корреляции
Идея для тех, кто может это реализовать. Сравнивать машинным зрением эти recurrent plots в поисках совпадений паттернов. Как замена беспонтовой корреляции
Раньше некоторые идеи ТС не мог проверить, т.к. упирался в низкую производительность некоторых алгоритмов. В данном случае именно так и произошло - альтернативный алгоритм позволил в оптимизаторе исследовать старую, как мир, идею, но не могущую ранее быть посчитанной за разумное время.
Когда нужно посчитать сотни миллиардов КК Пирсона при паттернах длинной в несколько тысяч, то низкая скорость казалось бы простой задачи становится непреодолимым узким горлышком. Можно начать говорить, что если задача видится слишком тяжелой с вычислительной точки зрения, то это плохо сформулированная задача со слабым пониманием. Возможно, и так. Но что сделано, то сделано. А посмотреть, как реализуют подобное другие - всегда интересно.
А если вы это еще и на GPU реализуете, цены вам не будет ))
Без понтов можно найти самый частый паттерн. Только какой в этом смысл?
Ну для стратегий на паттернах, вестимо ) не обязательно самый частый, вариантов может быть много
Ну для стратегий на паттернах, вестимо ) не обязательно самый частый, вариантов может быть много
Вот этого и не понимаю. Использовать данные паттернов полезно при сжатии данных с небольшой потереей информации (различные медиа). Но к ТС каким боком?
Проще всего говорить по этой теме на примере самого частого паттерна. Найти его - не архисложная задача.
Вот какая-то загагулина (паттерн) встречается чаще всех. Критерий его выбора - дело сейчас не так важно. Пусть загагулина есть. Как ее использовать для торговли?
Говорить, что если крайняя истории совпадает на первые 80% с загагулиной, то следующие цены пойдут так же, как оставшиеся 20% загагулины - чушь.
Вот этого и не понимаю. Использовать данные паттернов полезно при сжатии данных с небольшой потереей информации (различные медиа). Но к ТС каким боком?
Проще всего говорить по этой теме на примере самого частого паттерна. Найти его - не архисложная задача.
Вот какая-то загагулина (паттерн) встречается чаще всех. Критерий его выбора - дело сейчас не так важно. Пусть загагулина есть. Как ее использовать для торговли?
Говорить, что если крайняя истории совпадает на первые 80% с загагулиной, то следующие цены пойдут так же, как оставшиеся 20% загагулины - чушь.
Почему вы считаете что это чушь? если в массе случаев прогноз будет подтверждаться, на той же истории