Подниму вопрос, который многим интересен - какое API вы используете для написания роботов?
В комментариях просьба написать почему и планируете ли менять API в дальнейшем. Если планируете - что мешает вам поменять прямо сейчас.
P.S. Вариант StockSharp - использование S# для любого реализованного в нём API (Quik api, smartcom, alfa direct, alor, transaq, plaza2).
Плаза 2… для хфт (у меня на хфт акцент) альтернатив нет… использую полноценную сдк с фермой тестовых ботов, возможностью потиково записывать синхронно с точностью до млс данные по всем потокам с плазы в файл и тестовым сервером, на котором могу эмулировать торги как в реальном времени.
Karaya1, для ХФТ тестировать не по по тикам нужно, а по стаканам. А вообще потиковый бэктестер сейчас есть у многих. В том числе и у нас. Но, повторюсь, лучше все же стаканы. Разница в результаты порой такая же, как true и false.
Mikhail Sukhov, можно пару вопросов про гидру относительно квика и плазы?
Насколько сложно сделать там получение и архивацию сделок по всем торгуемым инструментам? Т е не настраиваемый список получаемых а все что торгуется аналогично файлам на фтп ртс.
Можно ли накапливать бидаски т е снепшоты к примеру таблицы котировок?
nfxzhzh, да оно уже все есть. Фильтр по инструментам выключите — и усе. У нас все, что Плаза льет, архивируется. Стаканы правильным пацанам можем подкинуть =)
Mikhail Sukhov, а из таблицы сделок в Квике? Не дорос пока до Плазы.
Про стаканы в документации написано, а вот что касается накопления таблицы котировок как? Поясню вот есть например опционная борда, хотелось бы иметь секундную историю бидасков. Теоретически из квика можно вытащить историю изменений но это уже совсем нереально круто, пусть хотя бы снепшоты.
Хочу добавить возвращаясь к дискуссии на пауке про датафид признаю Вашу правоту по необходимости работать с ТВС.
думал с чего начать. решил среднесрочные стратегии сначала в qpile автоматизировать, но смотрю в сторону стокшарпа. купайл только временное решение, для освобождения времени. по стокшарпу начал разбираться, возможно купайл брошу раньше, чем думаю :) для быстроты перехода на стокшарп имхо надо побольше примеров, простых стратегий, но от и до рабочих. либо какой-то простой шаблон-скелет. на таких примерах переходить или обучаться получается гораздо быстрее если человек подкован в программировании. пока выбор происходит в сторону, где быстрее можно запустить.
Александр Муханчиков, вот я их как раз и изучаю, поэтому купайл брошу скорее чем думаю. вобщем скажу так, что стокшарп только первым впечатлением отпугивает, потом понимаешь что все круто. ну может не примеры, а пошаговый гайд какой-то, в хелпе что-то подомная под квиком как раз видел
Горбунов Алексей, почему? там всё просто готовый робот всё на русском, только подставь условие исполнения всего 10 команд изучить-не надо быть программистом, в отличии от всяких шарпов, где сначала заплплати нереальным колчесвом времени сили т.д… а потом может чтото получиш. квик на порядок проще и надёжнее любого другого способа. Сложные языки оправданы только в случае очень сложных расчётов типа фурье, интегралы и т.д.
Роботорговец, qpile это из разряда — машина не роскошь, а средство для передвижения. Хочется от робота стабильной и комфортной его работы. На qpile такого не получишь.
Горбунов Алексей, для большинства проблема с какой стороны к стокшарпу подступиться. синтаксис c# не проблема. поэтому нужен гайд хороший от а до я 8) тогда будет самой популярной платформой — если вы к этому стремитесь конечно. с наилучшими пожеланиями :)
Александр Муханчиков, вполне. главное, чтобы было место, где можно быстро найти ответы на всякие вопросы как подключаться и следить за подключением/ как получить свечку/ как выставить ордера/ как управлять позой и размером позы. ну и т.п. и с примерами. все конечно имхо :) я вот реально разрываюсь сейчас начинать с купайл(куча примеров и достаточно описано все) и стокшарп (смущают подводные камни, которые могут встретиться, некий туман еще в голове)
Горбунов Алексей, да как тут раз всё стабильно, нет никаких постредников, выход сразу на биржу-надёжость. комфорт одинаковый, только квик уже готов к работе, а за шарп нужно работать отдельно-не нужные затраты.(повторюсь если у вас не сложный алгоритм типа черепашек-нидзя)
Роботорговец, > и надёжнее любого другого способа.
С учетом того, что C# разрабатывает команда из 40 человек, а Qpile поддерживают (даже не разрабатывают, а только лишь поддерживают) 0.5 сотрудника Арки, с вашим утверждением сложно согласиться. Тем более, что Квик сам по себе не является надежной платформой для роботов, о чем сами же создатели заявляли не раз. У вас видимо Квик не падал в течении торговой сессии ни разу.
reist, вы ответили на другую тему. русские вёдра штампуют 2 человека, а венецианские 100 человек-это не значит что в русских хуже переносить воду. кто там чё разрабатывал вообще пофиг, мы говорим о прибыли, т.е при тех же результатах торговли(надёжности и полученных реальных деньгах), на квике затрат меньшепри раз в 100000, чем на шарпах. #-крутая прога-не спорю, но для расчета пересечения 3-х линий, такая мощная система просто не требуется.
Использую QUIK API, DDE, Transaq2Quik. Переходить на что-либо другое не планирую, потому что этого более чем хватает и весь код написан мной, а значит я могу его менять как мне хочется.
Александр а вы не планируете создать свою базу данных? таких параметров как Кол-во заявок, ои, Общий спрос и предложение ну итд. и транслировать это. и как смотриш на это?
Mikhail Sukhov, серьезно 4 года, до этого баловался только. Забыл добавить — там где руками еще паралельтно много чего на MQL писано было под форекс. )
escoman, мне для статистики. Купельщики вот надеются по быстрому, за пару месяцев роботов освоить. А я вот не понимаю, как можно этому научиться, не потратив несколько лет как минимум. И знания языка программирования для меня не особо сильно помогает. Все время натыкаюсь то на фундаментальщину, то на математику.
Не совсем понятны мнения многих. Например, если человек владеет C#, то ежу понятно, что при первом взгляде на Qpile он его отметет за несовершенство. И зачем ему опускаться до менее совершенного языка. Но, если этот человек — здравомыслящий, он не будет его поносить, а просто поймет, что существуют разные задачи и разные подходы. Или вы делите, как дети, на тех, кто играет в сложные машинки и тех, кто играет в простые? РАЗНЫЕ ЗАДАЧИ!!!
Согласен с Работорговцем. Qpile за глаза достаточно для реализации большинства идей, где не нужна скорость больше 1 раз/сек. И вообще, чем старше человек, тем меньше кнопочек хочет на пульте телевизора. Я в молодости аж визжал, если в программе было как можно больше настроек, драйвера там менял всякие каждый день. А теперь — честь и хвала PnP! купил комп, а он сразу работает!!!
Меня от сток шарпа как и от шарпа вообще отделяет только неумение потоки программировать. Вернее не потоки, а изменеие из одного потока данных в другом.
Spekyl, самое интересное, что изменение данный в одном потоке и в нескольких ничем не отличается. Но знание потоков для роботов — это must have. Потому что биржа — потоковая модель. А не синхронная, как это любят представлять Велс или Квик.
escoman, событийная модель — это высокоуровневая обертка над потоками. И там количество сценариев ограничено. Поэтому сами потоки в любом случае нужно уметь использовать.
escoman, повторюсь, это больше стиль. Например, чтобы реагировать на изменения стакана или изменения внутри бара, то в Велсе и Квике нужно довольно хитро написать скрипт. Там нет события. Если же использовать события, то все намного проще:
riDepth.Changed += () =>
{
// логика реагирования на изменение стакана
// срабатывает точь в точь, когда он меняется,
// а не когда заканчивается интервал
};
Событийная модель делает это читабельнее:
this
.When(Depth.BestBidMore(upLimit))
.Do(/* обрабатываем конкретное правило повышения бида */);
escoman, лямбд… Не важно, можно и через обычные разработчики. Но смысл в том, что императивные языки не очень годятся под события. Тут рулит функциональный стиль. И C# медленно но верно к нему сползает. В следующей версии вообще поддержка событийного подхода будет на уровне языка. Тогда все станет еще роднее и удобнее.
Mikhail Sukhov, а есть пример с комментариями для тупых, или суть в двух абазацах. Я умом понимаю, что как-то просто все решается, но в большинстве книжек про многопоточность либо заумь (для меня, во всяком случае) либо кратко, что она вообще есть.
в стокшарпе потоковая модель косячная — правда имел дело только с квиковским апи — но все же — нафига на каждый колбак по потоку вешать — один поток рулез — гемора в разборе полетов на порядок меньше получается имхо
могу подискутировать но лень ))
потоки это зло если пользовать их неумеючи
если даже либа квика подразумевает мультипоточные коллбаки — я бы все равно все сводил в один тред — и никакой синхронизации и гемора — 50к небольших событий можно в секунду обрабатывать в одном треде — думаю столько ртс не снилось
я в потоках последние 6 лет)) — можно сказать собаку съел
правда не знаю спецификации взаимодействия сторонних с c#
но для того чтобы сказать что тредовая модель в стокшарпе убогая мне инфы достаточно
Хотя я в своём SAT тоже отказался от идеи использования потоков. Но там проблема другая — старые VCL-контролы не поддерживают одновременных обращений из разных потоков.
Поэтому, кстати, меня тоже заинтересовал S#. Хотя для позиционных роботов по фигу, что в одном потоке обработка идёт, что в разных. :)
насчет убогости стокшарповой модели — не вижу смысла иметь больше одного треда на биржу и если не хватает производительности то это уже кривые ручки…
если уж так хотите использовать пул потоков тогда должна быть четко документированная модель а не просто синхронайз везде — это хорошая база для дедлоков
хорошая практика в таких программах привязывать тред не к типу событий а привязывать инструмент к потоку — те вся маркет дата и все ордера для конкретного инструмента проходят в одном потоке
в доках нет правил копирования доменных объектов — надо все определять эмпирически — что копируется что модифицируется и синхронизованно и доступно между различными потоками неясно
вот например класс Security это по сути своей доменный объект но в нем присутствуют методы доступа к стакану которые в данной тредовой модели не могут не быть синхронизованны — те по сути это типа сервиса получается — но сервиса однобокого в плане что событий об изменения книги нет в этом сервисе — только получение стакана а события надо получать из другого источника, и вообще зачем тогда классу паблик конструктор если он должен быть гдето правильно инициализированн
такую багу даже недавно видел на форуме что номер транзакции не был инициализированн в событии трейда — если логика робота основывается на этом он просто его пропустит — это типичный кросскондишн
короче если покопаться то наверное еще куча всего найдется — нет ни времени не желания
А есть ли деньги у бизнеса на развитие за счет собственных ресурсов?
— Безусловно, есть.
В первом полугодии прибыль нефтегазовых компаний страны выросла до $32−39 млрд, что почти на 65% больше,...
Николай Иванов,
Проблема в том, что они на*** не нужны там никакие «корпорации» и прочие жыдоэскроу.
В нулевых мне мои 150квадратов на 10сотках в пригороде вышли в лям двести по кругу. С га...
Совкомбанк (Андрей Оснос): месяц назад мы считали, что ставка начнёт расти в 2025г. Теперь думаем, что будут расти дефолты, замедляться экономика. Этого хочет ЦБ. Поэтому ставка выйдет на плато Совком...
Власти хотят направить сбор за распространение интернет-рекламы на поддержку разработчиков софта и развитие сайтов, список которых определит правительство — РБК РБК ознакомился с версией поправок в за...
Власти хотят направить сбор за распространение интернет-рекламы на поддержку разработчиков софта и развитие сайтов, список которых определит правительство — РБК РБК ознакомился с версией поправок в за...
Теперь точно вклады заморозят! Иначе будет гиперинфляция. Сейчас это слышно постоянно, то тут, то там. Но велика ли эта угроза? Чтобы понять это, посмотрим сначала на 2008 год. И начнем с США, чтобы о...
Банк России отменяет ограничение ПСК по кредитным картам с 1 января по 31 марта 2025 года Совет директоров Банка России принял решение с 1 января по 31 марта 2025 года не ограничивать для кредитных ор...
Насколько сложно сделать там получение и архивацию сделок по всем торгуемым инструментам? Т е не настраиваемый список получаемых а все что торгуется аналогично файлам на фтп ртс.
Можно ли накапливать бидаски т е снепшоты к примеру таблицы котировок?
Про стаканы в документации написано, а вот что касается накопления таблицы котировок как? Поясню вот есть например опционная борда, хотелось бы иметь секундную историю бидасков. Теоретически из квика можно вытащить историю изменений но это уже совсем нереально круто, пусть хотя бы снепшоты.
Хочу добавить возвращаясь к дискуссии на пауке про датафид признаю Вашу правоту по необходимости работать с ТВС.
Бидаски конечно хорошо бы лить через стаканы но Квик не потянет мне кажется открытые стаканы по всем инструментам.
Спасибо за ответ.
Stock#
Wealth-Lab :)
transaq нравится больше но это все субъективно они оба хороши но Transaq лучше :)
см. профиль
Я собственно почему предложил видео-презентации сделать, потому что это будет более наглядно.
С учетом того, что C# разрабатывает команда из 40 человек, а Qpile поддерживают (даже не разрабатывают, а только лишь поддерживают) 0.5 сотрудника Арки, с вашим утверждением сложно согласиться. Тем более, что Квик сам по себе не является надежной платформой для роботов, о чем сами же создатели заявляли не раз. У вас видимо Квик не падал в течении торговой сессии ни разу.
почему не StockSharp? потому как код закрытый, ну и реализация на делфи для меня попроще, чем на C#
Если интересно, конечно. :)
исходников не будет?:)
да, чисто из любопытства — как интерпретатор реализован?
Правда его пришлось напильником дорабатывать. :)
По исходникам. Вопрос есть ли смысл?
Если совместную разработку делать, то можно и открыть исходники.
потому как совсем не програмёр и рынок ПОКА не основной доход, основная моя проблема — вера в робота и невмешательство в его работу…
О СтокШарпе знаю. Но проблематично перескочить со своих разработок на чьи-то.
Хотя, конечно, в СтокШарпе привлекает то, что библиотека поддерживается многими пользователями/разработчиками…
О том же Сток-Шарпе, например, я узнал ещё года 2 назад. Когда была только версия под Квик.
планирую использовать StockSharp
2008 — Eva
2009 — Dettier
2010 — robot_Panda
2011 — robot_PRADA
Т.к. СмартКОМ безбожно тормозил в те годы.
Использую c# и API к торговой платформе OEC Trader (брокер Open E Cry). Вот здесь лежит дока к этому АПИ:
openecry.ru/index.php/forum/5-torgovyj-terminal-openecry/117-dokumentatsiya-na-api-dostupa-k-funktsiya-terminala-oec-trader
Можем голосом пообщаться?
Я просто не понял сути понятия «поток» в данном контексте, который упоминал Spekyl.
Можно и с одним потоком событийную модель построить.
Я так понял, что Велс и Квик останавливают исполнение алгоритма робота на время, например, отправки заявки в шлюз?
riDepth.Changed += () =>
{
// логика реагирования на изменение стакана
// срабатывает точь в точь, когда он меняется,
// а не когда заканчивается интервал
};
Событийная модель делает это читабельнее:
this
.When(Depth.BestBidMore(upLimit))
.Do(/* обрабатываем конкретное правило повышения бида */);
Т.е. типа использование анонимных методов? Кажется это так называется.
Не буду больше мучать. :)))
потоки это зло если пользовать их неумеючи
если даже либа квика подразумевает мультипоточные коллбаки — я бы все равно все сводил в один тред — и никакой синхронизации и гемора — 50к небольших событий можно в секунду обрабатывать в одном треде — думаю столько ртс не снилось
правда не знаю спецификации взаимодействия сторонних с c#
но для того чтобы сказать что тредовая модель в стокшарпе убогая мне инфы достаточно
Хотя я в своём SAT тоже отказался от идеи использования потоков. Но там проблема другая — старые VCL-контролы не поддерживают одновременных обращений из разных потоков.
Поэтому, кстати, меня тоже заинтересовал S#. Хотя для позиционных роботов по фигу, что в одном потоке обработка идёт, что в разных. :)
LMAX — London MultilAteral Exchange. У них свой API, я использую .NET.
К трёхмерной графике отношения не имеет :)
если уж так хотите использовать пул потоков тогда должна быть четко документированная модель а не просто синхронайз везде — это хорошая база для дедлоков
хорошая практика в таких программах привязывать тред не к типу событий а привязывать инструмент к потоку — те вся маркет дата и все ордера для конкретного инструмента проходят в одном потоке
в доках нет правил копирования доменных объектов — надо все определять эмпирически — что копируется что модифицируется и синхронизованно и доступно между различными потоками неясно
вот например класс Security это по сути своей доменный объект но в нем присутствуют методы доступа к стакану которые в данной тредовой модели не могут не быть синхронизованны — те по сути это типа сервиса получается — но сервиса однобокого в плане что событий об изменения книги нет в этом сервисе — только получение стакана а события надо получать из другого источника, и вообще зачем тогда классу паблик конструктор если он должен быть гдето правильно инициализированн
такую багу даже недавно видел на форуме что номер транзакции не был инициализированн в событии трейда — если логика робота основывается на этом он просто его пропустит — это типичный кросскондишн
короче если покопаться то наверное еще куча всего найдется — нет ни времени не желания
в любом случае удачи — дело все равно полезное