Блог им. facepalm

[опрос] Платформа для алготрейдинга

[опрос] Платформа для алготрейдинга

StockSharp
AmiBroker
Metatrader
QUIK
TSLab
самописная на C++
самописная на C#
самописная на Delphi
самописная на Java
самописная на R
самописная на VB (Excel)
самописная на Python
самописная на другом ЯП
другое
Всего проголосовало: 97

Интересно, кто что использует.

Понятно, что варианты ответов могут не совсем правильно передавать суть. Т.к., например, StockSharp может использовать коннектор для QUIK.

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

В вариантах ответов не указал SmartCom (возможно, зря), поскольку, по-моему мнению, использование этой библиотеки ближе к варианту самописной платформы.
★4
18 комментариев
Как новичек написал Amibroker, т.к.:
1. Программа простая для понимания
2. Внутренний язык простой. Тысячи примеров программ на официльном сайте. Я как не программист смог достаточно бысто изучить его и написать первого робота.
3. Хорошее русское сообщество на Amisite, где всегда помогут советом. Так, например, мне там помогли найти коннектор к R, чтобы в Amibroker использовать весь функционал R.
4. С помощью AmiSharp коннектится к Quik и работает стабильно. Из Quik можно получать тики. Пробовал запускать типа hft: если три последовательных тика увеличиваются, то покупаем на 4-м по рынку. Продаем также. В целом работает, но из-за скорости Quik имеется большое проскальзование. Так, что лучше реализовывать идеи на минутках и выше.

В целом. При использовании Amibroker проблема не в программировании, а в поиске идеи для системы.

Сейчас смотрю в сторону C# и S#.
avatar
vito2000, Поддерживаю)
avatar
Вы бы объединили все пункты про самописную. Потому что споры какой язык программирования лучше — это из «другой оперы». Тут «на вкус и цвет...». Ответ то в этом случае простой: на каком лучше получается, на том и пиши. Вот я, например, С# взял только потому, что имел опыт программирования на С++ под MS-DOS в конце 80-х-начале 90-х. Но сказать, что-то использовал из его новомодной объектной ориентированности, не могу. Единственное, что я освоил в нем новое — это закачку данных из базы данных.
avatar
А. Г., «Потому что споры какой язык программирования лучше»

Нет никаких споров.
avatar
professor facepalm,

Дело не в этом. Как уже написал, я использую С#, но не поручусь, что это лучше, чем самописная, например на R.
avatar
Присоединяюсь к мнению уважаемого А.Г.
Лучшая платформа для алготрейдинга та, с которой трейдер умеет эффективно работать.
Сам пока пишу на QLua, но активно изучаю C# (опять же в связке с квиком). Что будет через 5-10 лет? Доживем — увидим…
avatar
Коробочные решения — более универсальны. И, возможно, будут удобны для большинства алгоритмов. Вы сразу решаете проблему с тестированием и отладкой ядра.
Но универсальность иногда урезает необходмый функционал и скорость работы. Писать что-то свое нужно на этапе, когда есть четкое понимание что писать, как и для чего.
avatar
Alex Hurko, судя по картинке из профиля, на Python программируешь :) Причём используется какой-то локальный сервер с котировками, работающий по REST. В чём смысл? Почему взаимодейтвие не напрямую с БД происходит?
avatar
professor facepalm, на python только тестирую. Набросать алго там намного быстрее, нежели на C#. Ну во всяком случае мне:) На локалхост котировки отдает API датафида (ActiveTick), по многим причинам мне удобнее юзать HTTP запросы для закачки котировок в MongoDB. Дальше я работаю уже с БД. То, что торгуется в основном работает на C#. Меньше проблем с интерфейсом + API терминала на C#. Но кое-что есть торгующее из питона и экселя. Все зависит от задач.Нет смысла писать нечто громоздкое ради 5 сделок в неделю.
avatar
Alex Hurko, А вы же раньше вроде MultiCharts'сом пользовались что с подвигло на переход на собственную платформу?
avatar
Игорь, и сейчас пользуюсь. В любой связке есть тонкие моменты, ограниченные функционалом платформы. Увы, есть стратегии которые проще полностью переписать.
avatar
Alex Hurko, «Меньше проблем с интерфейсом + API терминала на C#»

Можно ведь коннектор написать. Тогда сразу после тестирования стратегии можно будет запускать python-робота на реальной торговле.
avatar
professor facepalm, можно. Но это костыль. Iron Python не очень удачное решение из-за скорости и отсутствия поддержки многих питоновских либ. А связка питон + либа + сишарп имеет ряд недостатков. Например, проблема с ивентами. и тд.
avatar
Alex Hurko, «А связка питон + либа + сишарп имеет ряд недостатков. Например, проблема с ивентами. и тд.»

Ну это скорее не проблема, а задача. Решается она без особых сложностей. Вариантов много. Один из самых простых — это использовать redis (in-memory key-value database). Если конкретнее, то: redis.io/topics/pubsub
Суть в том, что из python можно подписаться на сообщения в БД по определённому адресу. И когда C# будет отправлять туда данные, то на стороне python'а они будут автоматически появляться. Нужно лишь поверх этого спроектировать простенький протокол (например, на основе json'а).
Есть и другие варианты: zeromq, grpc (точно не уверен), rest-сервер с вебсокетами.
avatar
professor facepalm, это собственно позволеят также перенести разработку всего того, что связано непосредственно с торговлей, на линукс. Оставив на винде только часть, взаимодействующую с redis и api терминала. Если, конечно, разработка на линуксе имеет какое-то занчение.
avatar
professor facepalm, да, это все возможно. Просто зачем извращаться, когда есть полноценное АПИ терминала на C# и АПИ датафида на C#? )) Если работать без терминала под FIX, тогда и потребности в C# не будет как-таковой. Там уже выбор больше и в плане языков и плане ОС. Универсального решения я думаю что нет. Все зависит от потребностей, скоростей, функционала и тд. Если оно работает в вба, то пускай работает в вба, усложнять не нужно:)
avatar
Alex Hurko, «да, это все возможно. Просто зачем извращаться»

Затем, чтобы робота надо было только один раз писать и с тестов можно было сразу запускать на реальной торговле. Без переписывания с python на другой язык и привязывания к api терминала/брокера.
avatar
professor facepalm, в идеале звучит хорошо. Но у меня так не получается. Практически под каждый алго приходится писать свой движок. Алгоритмы очень специфичны, увы. Проблема одного движка в том, что поменяв одно — начинает сыпаться другое. Больше времени уходит на отладку и тд. Но у меня опять же очень специфичные алго, там нет buy on the next bar и тд. В каждом есть своя проблема, свой прсчет, свои данные… Поэтому я и начал с того, что нужно сначала коробочные решения поюзать. Но увы я не видел ни одного универсального решения, которое могло бы сразу покрыть хотя бы 60% моих потребностей. И сам я тоже вряд ли смогу запихать все в одну коробку. Как-то так.
avatar

теги блога professor facepalm

....все тэги



UPDONW
Новый дизайн