SergeyEgorov
SergeyEgorov личный блог
12 ноября 2013, 10:20

Бесплатная библиотека для программирования роботов

Открываю исходный код, который мы используем для сборки наших торговых роботов.

Разработку я начал год назад и нашей главной целью было как можно быстрее, и как можно с меньшими затратами начать торговать алгоритмически. Цели как мне кажется мы вполне достигли, потому что используя наш подход мы сегодня можем реализовывать и ставить на торговлю новые алгоритмы очень быстро (в течение одного рабочего дня даже).

Я записал несколько коротеньких видео, все вместе они потянут на час с небольшим, в которых постарался показать концептуальную основу библиотеки и как с ее помощью можно за час собрать и запустить робота.


 
Видео можно скачать файлом отсюда. (Формат avi, размер 27.4 Мб)


 
Видео можно скачать файлом отсюда. (Формат avi, размер 135 Мб)

 
Видео можно скачать файлом отсюда. (Формат avi, размер 44.8 Мб)

 
Видео можно скачать файлом отсюда. (Формат avi, размер 146 Мб)

 
В ближайших планах записать несколько видео (возможно это будет еженедельно), последовательно демонстрирующих процесс доработки робота.

Исходный код библиотеки можно загрузить отсюда.

Исходный код адаптера для торговли через Ай Ти Инвест можно загрузить отсюда.

Исходный код робота, использованный при записи видео можно загрузить отсюда.

Весь исходный код в оптимальном объеме покрыт модульными тестами (сама библиотека около 700 тестов, код адаптера чуть больше 100 тестов). Часть тестов скорее являются интеграционными, потому что проверяют работу нескольких компонентов.

Тесты не избыточны и не покрывают весь код стопроцентно. То есть в процессе эксплуатации сейчас выявляются и наверняка еще будут выявляться ошибки или сбои для пограничных случаев, для которых нет тестов. В случае выявления таких ошибок, будут реализованы дополнительные тестовые наборы и с их использованием исходный код будет исправляться или трасформироваться.
29 Комментариев
  • Круто. Огромная работа проделана. А чем ваша библиотека отличается от S#?
  • Дмитрий Столетов
    12 ноября 2013, 11:28
    Пишите софт для smart-lab.ru/profile/DJSich/?
  • Kostya33
    12 ноября 2013, 17:33
    мне вот очень интересно смотреть трейдерский софт изнутри.
    Спасибо.
  • Kostya33
    12 ноября 2013, 18:32
    из того что заметил, интерфейсы было бы хорошо называть с заглавной I, это обычная практика, читать на мой взгляд удобнее. ISomeInterface
  • Изя 3%
    12 ноября 2013, 20:33
    Программисты — коммунисты. ) Сергей вот интересно, а какая мотивация бесплатно то все раздавать? Вот правда не понятно.
    А потом «ааа почему никто не покупает» ..))
    • Изя 3%
      13 ноября 2013, 21:43
      SergeyEgorov, те ваше потенциальное преимущество на рынке в виде знаний, готовой работающей (наверное ;) библиотеки, потраченного времени и денег вы добровольно и безвозмездно отдаете в расчете заработать как то потом, в другой, непрофильной (по всей видимости) для вас сфере… а ну ок )))
        • Изя 3%
          14 ноября 2013, 21:54
          SergeyEgorov, спасибо посмотрел. но полумертвые какие то проекты. потом ни одна не пригодна для торговли у нас например => бесполезные ).
  • Kostya33
    13 ноября 2013, 09:55
    абстрактный класс именуется так же, как и остальные классы. А вот определение интерфейса в абстрактном классе — это моветон, т.к. в C# нет множественного наследования. Поэтому интерфейсы отдельно, классы отдельно. И чтобы с первого взгляды было ясно что где, приписывают I
  • Kostya33
    13 ноября 2013, 10:57
    совершенно случайно такая книжка у меня есть, правда я ее не читал. а где в ней он про это пишет?
  • Kostya33
    13 ноября 2013, 13:59
    Такая книжка у меня тоже есть, и даже бумажная. многие советы из нее хорошие и правильные. Но то, что он написал на стр. 47, это бред. «Я не собираюсь сообщать пользователям, что они имеет дело с интерфейсом». Если он пользователю не сообщает об этом, интерфейс никуда не денется. И с первого взгляда в коде не понятно, от чего унаследован класс — от абстрактного класса или реализует интерфейс. И если реализацию интерфейса я могу прикрутить к своим классам, то унаследоваться от абстрактного класса я могу далеко не всегда. Вот, допустим у меня приложение на WPF и я использую много классов, унаследованных от DispatcherObject. Куда тут абстрактные классы прикручивать?

    Взамен отказа от префикса I, кстати Мартин предлагает гораздо более некрасивую альтернативу — именовать реализацию интерфейса с префиксом C или постфиксом Imp: CFactory или FactoryImp. Зачем это нужно — непонятно, ведь реализаций интерфейсов больше, чем самих интерфейсов, а в результате весь код будет состоять из CClass1, CClass2 и т.д.
  • Kostya33
    13 ноября 2013, 15:12
    а еще вопрос — как делаете визуализацию? рисуете ли графики, а если рисуете то в чем?
  • Kostya33
    13 ноября 2013, 15:39
    а почему тогда не реализовали исполнение стратегий из WealthLab? Ну или сделать хотя бы набор логики примерно такой же — DataSeries и т.д.
  • Kostya33
    13 ноября 2013, 17:02
    Ну никакого обмена данными с WL это не потребовало бы. А вот работа с DataSeries гораздо приятнее чем SiRtsSpreadFactory:SpreadFactory. Вы на каждую операцию 2+2 фабрику классов создаете? И интерфейс? Пачка перегруженных операторов DataSeries очень удобная и быстра в использовании. Да, LINQ запросы можно делать над любыми коллекциями, просто какой ценой? Производительность там удручающая. У меня свой многопоточный тестер (который прогоняет стратегии на тиках и сохраненных стаканах) и я знаю о чем говорю.

    И WL это совершенно не обязательно последовательность синхронных действий. Не нужно все делать в лоб. У меня есть примерно такой шаблон стратегии
    interface IStrategy
    {

    void Initialize();
    void CreateTimeScales();
    void Finish();
    void OnNewTicks(Listticks);
    void OnOrderComplited(MasterOrder order);
    void OnOrderCanceled(MasterOrder order);
    void OnOrderError(MasterOrder order);
    void OnNewTrade(MasterOrder order, TradeOperationRecord tradeOperationRecord);
    void OnNewDoM(DoM dom);
    void OnTimer();

    }

    это завернуто в набор кубиков конечного автомата стратегии. Все работает асинхронно.

    В инициализаторе создаю из DataSeries те фильтры, которые хочу

    BarDataScale scale = new BarDataScale(RobotData.Scale, RobotData.BarInterval);
    Bars ticker1Bars = DataSource[_ticker][scale];

    int period = RobotData[«Period»].ValueInt;

    DataSeries series1 = SMA.Series( (_ticker1Bars.Open + _ticker1Bars.High) / 2.0 );

    Можно сделать вот такой обработчик на новый бар
    BarsCollection barsCollection = DataSource.GetBarsCollection(scale);
    barsCollection.Cursor.OnPositionChanged += OnCursorPositionChanged;

    После этого DataSeries апдейтяться по вызову метода Update(), в том диапазоне, в котором нужно, без моего участия. Без всяких фабрик классов и LINQ запросов

    Т.е., где-то в OnNewTicks или OnTimer или OnCursorPositionChanged
    я делаю series1.Update() и уверен, что все последниее тики там есть, при чем там DataSeries сами разбираются, в каком диапазоне апдейтить

    Стратегии WL заворачиваются в такую логику достаточно хорошо + еще дополнительные плюшки в виде котирования, стаканов и т.д. :)
  • Kostya33
    13 ноября 2013, 20:23
    по LINQ, первое — это использование вместо коллекций с доступом по ключу, коллекций общего назначения с дальнейшими запросами наподобие Where, First и т.д. Приводит к полному обходу коллекции. Второе, LINQ ни как не может определить «тяжелые» свойства объекта — поля, доступ к которым занимает много времени. И когда в запросе одно и тоже поле используется N раз, время запроса увеличивается пропорционально в N раз. Особенно плохо, когда поле возвращает также результат LINQ запроса.
    Разумеется, те микросекунды, которые выкраиваются на этом, при работе робота в течении дня никак не заметны, это проявляется только при многократном прогоне стратегий на оптимизаторе.

    Про WL — у меня используется самописный контейнер и DataSeries, позволющие с минимум затрат импортировать стратегии. Код WL не используется
  • dhong
    19 ноября 2013, 21:30
    отлично, спасибо за дискуссию!

Активные форумы
Что сейчас обсуждают

Старый дизайн
Старый
дизайн