Блог им. 3Qu

Досужие размышления о Quik, Lua и Python.

    • 28 марта 2020, 16:03
    • |
    • 3Qu
  • Еще

Я уже писал, что у меня сделана C++ DLL, которая получает данные из Lua и пишет их в БД SQLite. Уже писал также, что DLL под Lua делается на раз, и даже приводил коды и шаблон проекта простенькой C++ DLL. Посмотрело несколько тысяч, скачало, аж 12 человек, применят от силы двое. КПД постов, прямо скажем, оч низкий.)

В DLL реализована как связь с Lua, и будет реализована сама стратегия, вот только не решил какая из них. Повторять старые стратегии на новой для меня платформе Quik уже неинтересно, а новых моделей АТС отработано уже несколько. Все моделируется в Python. Часть стратегий не требует сложной математики, и могут быть легко перенесены непосредственно на С++. Другие непосредственно в DLL перенесены быть не могут, т.к. используют пакеты Python — всяческие регрессии и машинное обучение.
В общем, получилось, что DLL является шаблоном для любой стратегии. Все необходимые для АТС данные доступны АТС — реал-тайм данные поступают в DLL непосредственно из терминала, а необходимая история пишется DLL в БД SQLite и читается АТС из базы данных.

Ну, а пока конкретная стратегия не выбрана неплохо заняться реализацией связи АТС -> Python.
Самым очевидным и простейшим видом такой связи является файловый обмен — АТС пишет запрос в файл, Python обрабатывает данные и пишет ответ в другой файл, АТС этот файл читает и использует данные по назначению. Я этот подход уже неоднократно ранее использовал в своих системах, он хорош еще тем, что при переходе на другие виды обмена (Сокеты, MMF и пр.) практически ничего переделывать не надо. Надо только перенаправить запросы в другую функцию. Скорость при таком обмене составляет ~10ms на запрос.
Файловый обмен оч.неплох также для всячесих отладочных работ, т.к. впоследствии легко заменяется другими видами обмена.

Вторым, и одним из самых распространенных является обмен информацией через сокеты. В С++ для этого существуют готовые библиотеки -
Класс CSocket и Класс CAsyncSocket. В Python также имеется библиотека Socket. Есть и другие библиотеки создания сокетов в Python так что реализация связи проблем не представляет.

Возможна также реализация связи через Pipes (именованные каналы). Соответствующие библиотеки также имеются как в С++, так и в Python. Многими pipes применяются, широко применяются, и они просто реализуются, а плохи только тем, что мне этот способ связи не нравится.)

Ну, и еще один способ связи — это связь непосредственно через базу данных. Коли уж база данных уже имеется в системе, то почему бы не создать пару таблиц, в одну из которых писать строки запросов к Python, а во вторую строки ответов. Связь через БД несколько быстрее файлового обмена, время передачи-приема составляет ~5-7 ms. Если еще учесть, что в таблице данные уже структурированы и не нуждаются в преобразовании к формату принимающей или передающей программ, то это дает дополнительный выигрыш во времени.

Последний, и самый сложный способ связи с Python — это связь через Python C-API. Соединяем DLL c Python, и непосредственно из DLL вызываем функции Python.
Я не сторонник последнего способа. Мне кажется, что Python должен быть отдельным приложением работающим независимо, и асинхронно (независимо от DLL) обрабатывающий данные, и выдающий их по запросу из DLL или просто асинхронно отправлять туда уже готовые результаты. Тем более, что все реал-тайм данные Python может легко получать из базы данных.
Задачей непосредственно АТС во всех этих случаях является постобработка всех полученных данных и принятие решений, а от составных частей особого быстродействия не требуется — доли секунды, или даже несколько секунд особой роли для сделки продолжительностью даже в несколько минут не играют.
Кстати уж, время реакции человека на внешние факторы составляет примерно 2с. Даже если вы оч тренированы, то все равно это время составит 0.5-1с, однако люди руками успешно скальпят и играют интрадей, и никого такие задержки не смущают. В любом случае, т.к. решение принимается в АТС на основе совокупности реал-тайм и внешних данных обработки, реакция системы будет лучше реакции человека.

★12 | ₽ 5
Я предпочитаю файлы. HFT всё равно не обгонишь, а для долгосрочных стратегий — самое оно. Тупо, просто, универсально, надежно, связи между любыми языками и платформами.
avatar

Turbo Pascal

Круто было бы чтобы кто-то создал курс HFT на Python для чайников…
avatar

Lord Barrington

Lord Barrington, 
 HFT на Python
а это реально?
avatar

Андрей К

Андрей К, На самом деле, это оч интересный вопрос. Я ответ не знаю.
Если по аналогии, то скальпить с помощью Питон вполне реально. Именно, не на Питон, а с помощью Питон.
Скажем так, Питон обсчитывает нужную статистику — это медленно меняющийся процесс и не требует значительной скорости, а принятие решений и торговля на основе этой статистики и реал-тайм данных осуществляется уже быстрым процессом, на С++, например.
avatar

3Qu

Lord Barrington, а есть такой курс хоть на каком-то языке, можно просто на русском (ну, или на английском, что менее предпочтительно, конечно)? Без программ но с формулами…
avatar

tranquility

На рынке тихо станет, обязательно изучу.
avatar

Max Skinner

1. Есть два широко используемых протокола:
TCP/IP
HTTP
Причем HTTP  часто отдают предпочтение, потому что он через брэндмауэры пролезает.

2. В Вашем случае, конечно, необходимо использовать
TCP/IP и далее по убыванию
Pipes
DataBase

3. Если Приложение на Python + Мachine Learning на VM в Облаке Google-a,
то HTTP,
TCP/IP может не пролезть, но попробовать можно.

4.
Файловый обмен оч.неплох также для всячесих отладочных работ, т.к. впоследствии легко заменяется другими видами обмена.

 Технологии отладки ПО не должны использоваться как дополнительные факторы при выборе того или иного метода обмена данными,
а также влиять на выбор архитектуры и реализации бизнес логики Приложения.

Если у Вас это так. То значит, что в технологиях отладки что-то не так.
ПРЕКРАЩАЙТЕ ДЕБАЖИТЬ и ПИШИТЕ ТЕСТЫ.

5.
Надо только перенаправить запросы в другую функцию.

Не нужно лазить и менять что-то сто раз  в написанном коде.
Написал код, тесты запустил, все ок, Далее в код не лезем.
Точка.
В этом Вам помогут Интерфейсы,  Абстрактные модели, Dependency injection

Почитайте еще про  SOLID

Желаю сделать правильный выбор и успехов в реализации задуманного
avatar

_sg_

_sg_, а кто против?
Что касается файлового обмена, то для отработки технологий обмена, когда еще ничего не определено и все меняется по ходу пьесы, это самое оно.
Кстати, менять ничего не надо, заменяешь один объект другим, и все дела.
avatar

3Qu

помню тоже этой хнёй занимался. потом бросил.
avatar

Kapeks

Я выбрал сокеты, как самый прямой путь
avatar

Дедал

Дедал, Да, сокеты -это оптимальный вариант, в предыдущих системах он был реализован. В этой системе уже изначально есть БД, и возможно не стоит дополнять ее сокетами и ограничиться запросами к БД. Тем более 5-7 мс на запрос от передачи до приема — это вполне приемлемая скорость.
Однако, решение еще не принято. Посмотрим.
avatar

3Qu

 Люди, которые разрабатывали систему, которая гоняет данные между компами стоящими в одной комнате (или здании) говорили, что именованные каналы, весь этот нетбиос — отстой, сокеты — рулят. Правда, тут кто-то меня переубедил, что вроде и не такой отстой, а даже быстрее сокетов может быть, но я так понял, это если связь идет между двумя процессами запущенными на одном компе. Но все равно сокеты представляются лучшим вариантом из-за их универсальности. Один раз написал — и тебе уже нет никакой разницы где физически крутится тот процесс.
avatar

tranquility

еще RPC, нынче модный, есть
avatar

day0markets

www
avatar

ГИЧ

Цитирую Вас: "… у меня сделана C++ DLL, которая получает данные из Lua и пишет их в БД SQLite..." Можно как-то завладеть исходниками такой библиотеки, которая и получает из луа и передает в SQLite. Просидел 2 дня пытаясь сделать сам… устал… остается только попрошайничать. Ответить можно в 
md110 сбка inbox.ru. Согласен на любой ответ, лишь бы он был:) Спасибо.

avatar

ГИЧ

avatar

luks sluk

luks sluk, спасибо за ссылку. Действительно хороший материал для понимания dll. Я, правда, отказался от dll в пользу связи между Quik и метатрейдером5 через базу данных sqlite3. для меня это реализовать проще. Еще раз спасибо.

avatar

ГИЧ


....все тэги
2010-2020
UPDONW