Блог им. 3Qu
Сижу как-то раз за рюмкой чая (это было за год, два или три до моего прихода на Smart-Lab} и приходит мне в голову мысль — а почему бы не попробовать прогнозировать котировки.
Прогноз, естественно, на ТФ 1м, который я использую. Время прогноза пусть будет — 5 минут — вполне достаточное для моих сделок, а недостаточно, так прогноз можно и повторить на следующие 5 минут. Архивы котировок по фьючерсам SBRF и GAZR тоже имеются, минимум за год-два за последние 3 месяца перед экспирацией — хватит и на отладку и на проверку.
Все есть, только как реализовать прогнозирование? — ни одной мысли.
Собственно, не особо мне это было и нужно, рабочая система у меня уже была и меня она вполне устраивала, но мысль о прогнозировании засела, и я время от времени ее думал.
Ничего сколь-нибудь конструктивного в голову не приходило, и было решено для прогнозирования использовать нейросеть, тем более, незадолго до того я немного занимался машинным обучением и нейросетями в том числе.
От использования каких-либо предикторов сразу отказался. Плюс 2-3 слоя к нейросети, и если в данных есть какие-либо взаимосвязи, НС сама внутри себя построит нужные ей предикторы. В общем, подаем на НС поток цен 15-20 отсчетов Vc={C(t0-20),C(t0-19),...C(t0)}, нормируем их к динам диапазону НС — Vcn={c(t0-20),c(t0-19,… c(t0-1), 0} — c(t0) у нас всегда = 0, и пусть НС сама мучается с прогнозированием и поиском c(t0+5). И еще, у всякого метода есть область применимости, потому нельзя учить чему попало. Для этого из обучающей и проверочных последовательностей по возможности исключаем области истории, где прогнозирование невозможно. Иначе получим нечто такое.
По Х — прогноз значения цены С(t0+5),
по У — реальное значение цены С(t0+5)
Т.е., не получили ничего
Для реализации прогнозирования была выбрана распространенная и не самая сложная библиотека Python scikit-learn, обычный многослойный перцептрон, где-то ~150 нейронов. Обучаем на истории 3 месяца до экспирации фьючерса SBRF или GAZR — это где-то не более 15 минут, проверяем на тех же фьючерсах с другой датой экспирации. Получаем прогноз нормированного значения цены через 5 минут — c(t0+5).
По Х — прогноз нормированного значения цены c(t0+5),
по У — реальное нормированное значение цены с(t0+5)
Прогноз в области нуля для сделок нас не интересует. Прогноз же в области отличной от нуля вполне удовлетворителен и может быть использован для открытия и закрытия сделок. В ходе сделки прогноз может быть повторен для дальнейшего продолжение сделки.
Что же мы имеем. Мы видим, что для прогноза на 5 мин уже вполне достаточно жалких 150 нейронов. У таракана около 1 млн. нейронов.
Оказывается, для прогнозирования котировок и трейдинга мозгов нужно много меньше чем у таракана. Как-то даже обидно. Хотя, кому как.
Данные для графика 2 в студию, плз. 2 инструмента, 1 линейный прогноз и 1 временной интервал.
С уважением
Вчера прогнал свою ТС ку — как часы, риски вижу заранее, понятен потенциал движения, знаю где ждать и какой сценарий. Соотношение риск к профиту можно брать 1 к 5, 1 к 20 и даже выше — нет предела.
Вам CashKing просто так писал что ли? Я вот его читал внимательно, все по делу.
smart-lab.ru/mobile/topic/690717/
smart-lab.ru/r.php?u=https%3A%2F%2Fm.lenta.ru%2Fnews%2F2021%2F04%2F15%2Fphysics%2Famp%2F&s=1491763882
Вы, кстати, противоречите сами себе.)
smart-lab.ru/blog/723802.php
Получите первую картинку.
Почему решили использовать лог.регрессию, а не линейную?
Если по входам — убрать выбросы.
Книга старая, возможно и устаревшая. Хотя, основы не стареют.
Хорошо и понятно написана.
Вопрос 2: насколько быстро модели обучаются? Для режима реального времени подойдет ли?
Какие конкретно модели нейросетей на Ваш взгляд лучше подойдут для алготрейдинга?
Там есть так называемая 3х звенная архитектура. Если коротко:
Есть сервер БД: это либо бесплатный PostgreeSQL либо платный Microsoft SQL. Операции в нем делает так называемый сервер предприятия 1С 8. Суть его работы: он читает предварительно подготовленный код (назовем это псевдокод) который выполняют тригеры БД. Сервер 1С запускает по 1 процессу на каждое ядро имеющегося ПК/сервера. Соотвественно каждый из этих процессов асинхронно делает все сам с БД. Я так понимаю на С++ все это придется писать самому.
Так что если кто то хочет выжать все из квика то смысл примерно такой:
1 Устанавливаем в качестве сервера БД Microsoft SQL
2 Делаем несколько регламентных заданий, каждое из которых дергает либо 1 инструмент из ODBC либо несколько.
Я так понимаю быстрее чем тригеры MS SQL никто ничего пока не придумал. С++ это клиентский интерфейс писать и файловые базы
Только вот происходят ли на нашем рынке такие активные движения цен? Есть ли смысл так мучать систему бесполезными расчетами
Уточнение: 1С написан на с++. Соответственно все что в нем есть и все что он делает как тригеры для сервера БД это тоже как если взять другой компилятор С++. Допустим Вы до этого писали на компиляторе от Майкрософт а взяли от Борланд (если такая фирма еще есть). ТОлько назовите этот компилятор 1С
Еще уточнение:
Можно в квике сделать несколько таблиц в каждой из которых по 1 инструменту и каждая выводит в свой ODBC источник. Тогда уж точно выжать все получится.
www.anekdot.ru/id/363956/
Лично мое мнение ( сугубо частное)
У тебя это, скорее, не мнение, а «не знаю и знать не хочу»…
Подробно не гуглил вот первая же ссылка
Так как я программист 1С то соответственно каждый кулик свое болото хвалит
Динамический список :
v8.1c.ru/platforma/dinamicheskiy-spisok/
Система компоновки данных
v8.1c.ru/platforma/sistema-komponovki-dannykh/
Сервер 1С Аналитика
analitica.ru/
Если у тебя есть примеры в 1С — полный вперёд!
Не уверен, что 1С сможет даже строить регрессию по тикам в 0.001 сек, хотя бы в 0.1 сек. Принимая и возвращая данные в Quik — бог весть каким каналом.
Это уже задача для индикатора — его надо перерисовывать чаще, чем раз в минуту.
Как будто есть чей то робот который щедро раздает всем по выгодным ценам волатильность
С како бы скоростью чей либо робот ни выставлял заявки наша заявка в стакане уже есть. Если наступает момент когда в стакане только она то она исполнится.
Возможно я не прав но если например биржа обрабатывает стакан со временем в наносекунды а поступают заявки новые в микросекундах то все равно рано или поздно проскользнет на бирже запрос к БД биржи что типа получить все что в стакане на текущую наносекунду. (Т.е. скорость поступления заявок наверняка меньше, чем скорость их обработки биржей. Особенно в последние полгода)
И вообще наверняка большинство роботов выставляют не рыночные а лимитные заявки. Поэтому скорость вообще не важна. Пока не появится удовлетворяющая встречная лимитная заявка стакан вообще не сдвинется
Но если захочешь отследить ВСЕ бумаги хотя бы только MOEX, — Quik забуксует с таким множеством графиков.
Тебе нужно какое-то интернет-приложение, запрашивающее данные напрямую с биржи. По RSS или не знаю, как там ещё.
40 из них в режиме «3-4 раза в минуту»
остальные в режиме 1 раз в 5-8 минут.
Это у меня 2- звенная архитектура сейчас
В 3-звенной все это ускоряется в разы.
(в августе mail.ru закрыл аренду серверов в облаке поэтому перешел на двухвенку на своем ноуте не самой большой мощности). Как только биржа оживет вернусь в 3 звенку.
Данные принимает и выдает QUIK от СбербанкБрокер
PS обращаться к БД для сохранения и обработки коротенькой последовательности чисел, то же самое, что просить Путина починить кран на кухне.
Пусть даже не коротенькой, но без никаких реляционных связей. Что тут делать БД!?
Там много чего еще есть.
sqlite.org/docs.html
Можно также на C/С++ писать, если есть желание.
Так что «База данных» у меня — папки-каталоги с текстовыми файлами. Не залезая в СУБД, могу преобразовать, разделить, соединить любые файлы.
Всё как на ладони. И эти же файлы с разделителями ";" Excel читает как родные — так я настроил Windows.
Все держу в SQLite, в том числе, используется для работы ТС.
Нашел у себя на СЛ.
Но помимо скорости — «не умножай излишне сущности».
Делаем БД SQLite в оперативной памяти (есть такая опция) и работаем запросами.
Ах,, да, еще многопользовательский доступ к массивам-векторам надо организовать, мьютексы и пр. хрень — этого добра и так есть. В БД это все уже есть.
А я когда загружаю текстовый файл в память — строю по ходу индекс начала каждого дня. Даты упорядочены — бинарный поиск.
А много-потоковый доступ к истории котировок — только по чтению. Какие мьютексы!?
От части этой работы БД избавляет. Может несколько теряется быстродействие, но большая экономия работы и моего времени…
Макс скорость дает Луа С API, и после преобразования данных уход в другие потоки.
А если не хочешь вычислять асинхнонно — никто не мешает, повиси в синхроне в main() функции Lua-скрипта.
Пусть даже не 15-20 баров, а хоть 15-20 сотен или тысяч — без разницы. Но вообще-то каждую минуту нужно передать только один новый бар.
Git-компилятор в Lua разгоняется до скорости native C уже на второй итерации.
Да, согласен. Даже 20 мин не надо, достаточно передать 1 мин, остальные уже там.
Перевожу ваши слова на русский — с рынком можно и нужно завязывать.
Для многих это самое правильное решение
3Qu, нет, не про любую, но про предложенный вами подход — не просто можно, а нужно. Он изначально мертворожденный )
А завязывать с рынком не нужно, играйтесь, кто запрещает-то?
Кстати, почти год на рынке не играю. Догадайтесь почему? Нет, не проиграл.)
Сами алгоритмы, извините, без комментариев. В принципе, пара фильтров и обработка их данных.
Что-то типа такой
Тест за 3 месяца на одном фьючерсе SBRF.
По x- номер сделки, по У — накопленная прибыль в пунктах SBRF.
Это один из тестов современной модификации той стратегии, который тоже нет смысла доводить до реальной ТС — теперешние комиссии забирают чуть не половину прибыли, плюс потом еще налоги.)