Машинное обучение в трейдинге: теория, модели, практика и алготорговля - страница 298

 
Andrey Dik:

Что лучше, потратить немного больше времени на разработку, но потом всегда быстро считать, или быстро разработать и потом всегда мирится с тормознутостью расчетов?

Если в R быстро разрабатывать но медленно считать, то где тогда считать? Побыстрому разработать суперкар который медленно ездит? Нахрен нужен такой суперкар.


В исследовательских задачах на первый план выходит именно скорость разработки. Вместо человека, который пишет супер-быстрый код, но проверяет 1 гипотезу в день, на работу запросто возьмут человека, который пишет медленный код и запускает расчёты на всю ночь, но к следующему дню у него оказываются проверены 20 гипотез.

Для production-реализации модели проще взять ещё одного человека на небольшую зарплату, который будет переписывать на быстродействующем языке наиболее перспективные модели. Программистов-то много, конкуренция высокая; а вот исследователей, способных придумать что-то новое, надо ещё поискать :P

Это обычная практика. Поищите вакансии quantitative researcher и quantitative developer. От первых обычно требуют знания R/Python, от вторых - C++/Java.

 
anonymous:


В исследовательских задачах на первый план выходит именно скорость разработки. Вместо человека, который пишет супер-быстрый код, но проверяет 1 гипотезу в день, на работу запросто возьмут человека, который пишет медленный код и запускает расчёты на всю ночь, но к следующему дню у него оказываются проверены 20 гипотез.

Для production-реализации модели проще взять ещё одного человека на небольшую зарплату, который будет переписывать на быстродействующем языке наиболее перспективные модели. Программистов-то много, конкуренция высокая; а вот исследователей, способных придумать что-то новое, надо ещё поискать :P

Это обычная практика. Поищите вакансии quantitative researcher и quantitative developer. От первых обычно требуют знания R/Python, от вторых - C++/Java.

А не проще ли пользоваться готовыми и быстрыми библиотеками с++? вместо того, что бы пользоваться тем же, но медленным в R при "быстрой разработке"? Вы, да и многие другие тут, постоянно делаете подмену понятий. Точно так же можно "быстро разрабатывать" и в C-подобной среде. Или что бы работать в R не нужны соответствующие познания в датамайнинг и статистике? Точно так же нужны знания и при разработке на С. Так зачем делать двойную работу?

И я не знаю про какую такую "обычную практику" Вы говорите, а я привык делать сразу хорошо и один раз.

Я за свою инженерную практику часто видел людей, которые почему то думали, что если они будут использовать супер-пупер удобные в разработке программные комплексы, то у них будет обязательно получаться всё хорошо... Но они не могли понять одного - что бы всё получалось хорошо нужно другое: сало в голове.

 
Andrey Dik:

А не проще ли пользоваться готовыми и быстрыми библиотеками с++? вместо того, что бы пользоваться тем же, но медленным в R при "быстрой разработке"? Вы, да и многие другие тут, постоянно делаете подмену понятий. Точно так же можно "быстро разрабатывать" и в C-подобной среде.

Выбор языка - ваше право и личное дело. Насчёт библиотек - увы, для сколь-нибудь современных или необычных алгоритмов, реализовывать придется всё самостоятельно. Скажем, для расчёта "bipower variance" (что бы это значило? :D) я библиотек не нашел.

Или что бы работать в R не нужны соответствующие познания в датамайнинг и статистике?

Не утверждал такого и не поддерживаю это мнение.

И я не знаю про какую такую "обычную практику" Вы говорите, а я привык делать сразу хорошо и один раз.

Я за свою инженерную практику часто видел людей, которые почему то думали, что если они будут использовать супер-пупер удобные в разработке программные комплексы, то у них будет обязательно получаться всё хорошо... Но они не могли понять одного - что бы всё получалось хорошо нужно другое: сало в голове.

Моя практика в неких проектах со сложностью ## человеко-лет, где 95% кода написано на R, показывает, что для разных задач хороши разные инструменты, иногда даже медленные, если они используются для прототипов, а не для продакшена. В индустрии quantitative finance использование разных инструментов на разных этапах разработки - обычная практика, которая подтверждается требованиями к специалистам на разные вакансии. Упомянутые мною проекты стали бы сложнее на порядок, если бы они сразу реализовывались на C-подобном языке, даже универсальными солдатами, которые знают и умеют всё и сразу пишут решение задачи, без какого-либо этапа исследований.

За сим откланяюсь.

 
Andrey Dik:

А не проще ли пользоваться готовыми и быстрыми библиотеками с++? вместо того, что бы пользоваться тем же, но медленным в R при "быстрой разработке"?  

Когда обсуждается R я всегда стоял на комплексной, системной оценке этой "системы графики и статистики". сам алгоритмический язык вообще не упоминается в названии.

Лобовой сравнение быстродействия кода на R и как выше кода на мкл, или другом языке программирования, на конкретном, локальном примере совершенно НЕ корректно, так как ТС никогда не состоит как обсуждалось выше из функции корреляции, а всегда это большой набор, состоящий из кода и обращения к функциям. Так как R имеет огромный набор функций, то обычно код имеет небольшое число строк (1000 строк - это много), но очень емких содержательно.

Саму программу, которая решает некую содержательную проблему, можно грубо разбить на две части:

  1. алгоритм в виде кода, написанного на R
  2. обращение к функциям, для которых R является оболочкой.

По п.1 если пришлось написать значительные объемы кода, то вопрос быстродействия может быть очень серьезным. Имеется три пути преодоления:

  • преобразование в байт-код
  • распараллеливание на все ядра и/или соседние компьютеры. Это штатные средства и делается очень просто, если позволяет алгоритм
  • переписывание на другой язык, компилирующего типа. Сишные языки являются родными для R и процесс таких вставок хорошо документирован. 

По п.2 в смысле быстродействия дело обстоит совершенно иначе и я сомневаюсь, чтобы без специальных усилий при обыденной разработке мкл-программы удастся по быстродействию превзойти R. 

Например.

На поверхности лежит то, что в R операции над векторами и матрицами являются базовыми. Выражение вида a <- b*c исполняется библиотекой Intel. Циклов нет. Это доступно всем, каких-либо дополнительных знаний или усилий не требуется. При разработке мкл-программы скорее всего будут использованы циклы, хотя также имеется возможность обратится к этой же библиотеке (если программа не для маркета), но требуются достаточно высокого уровня знания и усилия для достижения одинакового результата.


Но это не все.

Если мы обращаемся к вычислительно тяжелым алгоритмам, а это обращения к функциям R,  то сам разработчик, столкнувшись с проблемой быстродействия, озаботился этой проблемой и обычно решил проблему на этапе разработки. Обычно это решается либо написанием сишного кода, либо обращением к библиотекам на С или Фортране. Кроме этого, в таких алгоритмах среди параметров обращения имеется возможность указания использования многих ядер.  Все это разработчик на R получает автоматически, не прилагаю усилий. Можно полностью сосредоточиться над сутью ТС, а не над техникой реализации. Сомнительно, чтобы разработчик мкл-программы сможет превзойти разработчика функций на R по банальной причине - надо специально работать над быстродействием, а не над сутью ТС.


Из всего написанного следует, что корректным сравнением быстродействия было бы на писание реального кода ТС на мкл и такого же кода на мкл+R (в R нет торговых приказов) и сравнить. Но во всей красе - а оно нам надо?

 
mytarmailS:
Кто нибудь пробовал работать с recurrence plots? почитать можно тут https://habrahabr.ru/post/145805/   , в частности подсовывать МО вместо сырых ВР? как вариант может сойдет


и‌ еще на почитать http://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf


Идея для тех, кто может это реализовать. Сравнивать машинным зрением эти recurrent plots в поисках совпадений паттернов. Как замена беспонтовой корреляции
 
Maxim Dmitrievsky:

Идея для тех, кто может это реализовать. Сравнивать машинным зрением эти recurrent plots в поисках совпадений паттернов. Как замена беспонтовой корреляции
Без понтов можно найти самый частый паттерн. Только какой в этом смысл?
 
fxsaber:

Раньше некоторые идеи ТС не мог проверить, т.к. упирался в низкую производительность некоторых алгоритмов. В данном случае именно так и произошло - альтернативный алгоритм позволил в оптимизаторе исследовать старую, как мир, идею, но не могущую ранее быть посчитанной за разумное время.


Когда нужно посчитать сотни миллиардов КК Пирсона при паттернах длинной в несколько тысяч, то низкая скорость казалось бы простой задачи становится непреодолимым узким горлышком. Можно начать говорить, что если задача видится слишком тяжелой с вычислительной точки зрения, то это плохо сформулированная задача со слабым пониманием. Возможно, и так. Но что сделано, то сделано. А посмотреть, как реализуют подобное другие - всегда интересно.


А если вы это еще и на GPU реализуете, цены вам не будет ))
 
fxsaber:
Без понтов можно найти самый частый паттерн. Только какой в этом смысл?

Ну для стратегий на паттернах, вестимо ) не обязательно самый частый, вариантов может быть много
 
Maxim Dmitrievsky:

Ну для стратегий на паттернах, вестимо ) не обязательно самый частый, вариантов может быть много

Вот этого и не понимаю. Использовать данные паттернов полезно при сжатии данных с небольшой потереей информации (различные медиа). Но к ТС каким боком?

Проще всего говорить по этой теме на примере самого частого паттерна. Найти его - не архисложная задача.

Вот какая-то загагулина (паттерн) встречается чаще всех. Критерий его выбора - дело сейчас не так важно. Пусть загагулина есть. Как ее использовать для торговли?

Говорить, что если крайняя истории совпадает на первые 80% с загагулиной, то следующие цены пойдут так же, как оставшиеся 20% загагулины - чушь.

 
fxsaber:

Вот этого и не понимаю. Использовать данные паттернов полезно при сжатии данных с небольшой потереей информации (различные медиа). Но к ТС каким боком?

Проще всего говорить по этой теме на примере самого частого паттерна. Найти его - не архисложная задача.

Вот какая-то загагулина (паттерн) встречается чаще всех. Критерий его выбора - дело сейчас не так важно. Пусть загагулина есть. Как ее использовать для торговли?

Говорить, что если крайняя истории совпадает на первые 80% с загагулиной, то следующие цены пойдут так же, как оставшиеся 20% загагулины - чушь.


Почему вы считаете что это чушь? если в массе случаев прогноз будет подтверждаться, на той же истории