Показаны сообщения с ярлыком Торговый робот. Показать все сообщения
Показаны сообщения с ярлыком Торговый робот. Показать все сообщения

среда, 15 июня 2011 г.

2-ой вебинар по роботам.

Сегодня, в 20 часов будет проводить вебинар по роботам Павел Касаткин. Павел является создателем адаптера под OpenQuant для Квика (помимо того, что мы с ним начинали делать Stock# вместе). Так что хорошая возможность задать вопросы тем, кто был на первом вебинаре, так и кто его пропустил.

понедельник, 30 мая 2011 г.

Торговые роботы на заказ от команды Stock#

Команда создателей Stock# открывает сервис по разработке торговых роботов и аналитических программ на заказ.

Для программирования роботов используется язык C# и уникальная платформа Stock#. Поддерживаются все торговые терминалы, включая прямые подключения к биржам РТС и ММВБ. Специально для Вашей стратегии будет разработан удобный пользовательский интерфейс и предоставлена качественная техническая поддержка.

Отправить заявку для оформления заказа Вы можете на странице http://stocksharp.com/robot/.

понедельник, 16 мая 2011 г.

Вебинар по роботам. Отчет

3 мая я вел вебинар по роботам на C#. Рассказывал по Quik API, что такое Stock# и как лучше писать бота. На выходных получил материалы и публикую их в блоге. Видео выложил сюда. В текстовом виде опубликовано http://finlabportal.ru/2011/05/s-roboty-pr...mixaila-suxova/ http://finlabportal.ru/2011/05/otvety-na-v...mixaila-suxova/

Местами волновался, местами смеялся. Мой первый опыт в вебе, так что сильно не пинайте.

вторник, 26 апреля 2011 г.

Бесплатный вебинар по роботам на C#

Во вторник, 3 мая в 20 часов состоится вебинар. На вебинаре я расскажу про сам язык C#, чем он отличается от других языков, в чем он программируется, и как выглядят роботы, написанные на таком языке.

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

пятница, 22 апреля 2011 г.

суббота, 19 февраля 2011 г.

Визуальные редакторы

Давно не писал беллетристику по роботам. Но на днях прислали ссылку на комоновский тред по tslab. Зашел посмотреть и увидел ЭТО:


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

Даже мои конкуренты по API для роботов - cofite - ввязались в это направление (судя по качеству картинки, пока не так далеко продвинулись, как tslab):


Немного теории о визуальном программировании. Появилось оно в лохматом году, наверное, даже раньше, чем привычные уже языки C, Паскаль и Бейсик. Помните блок схемы, что в школе на уроках информатики нас учили? Так вот, это прародитель всех нынешних редакторов. Эйфория по таким редакторам была еще чаще, чем кризисы в экономике. Каждый раз какая-то компания выдумывала очередной подход в решении проблемы визуального кода, маркетологи это разносили, но итог всегда был один - не взлетало. Даже Майкрософт вляпывался в эту направление. И так же терпел неудачу. А он то новатор (-аггрегатор) всего, что есть сейчас у программистов.

В чем причина провальности таких решений? В направлении. Людям, которые только изучают программирование, визуальный редактор только навредит. Он дает первоначальный вау фактор, который исчезает уже ко второму дню использования. Через неделю, код будет выглядеть как на картинке. И вот тут как раз и происходит крах такого подхода. Они были призваны упростить программирование. А вместо этого, происходит усложнение. И более того, код в текстовом файле начинает занимать значительно меньше места, чем вся эта мега-диаграмма, не влезающая аж 8 мониторов. А уж как ее тестировать - у-у-у-у. Это отдельная тема мазохизма.

И что же получается? Почему до сих пор создают такие редакторы, и даже крупные компании? Там сидят одни дураки? Отнюдь. Как я уже говорил, все дело в направлении. Направление таких редактором - это визуализация сложных процессов (масштаба компании) с возможностью встраивания готовых блоков. А когда на таком инструменте новички без опыта (а именно на них почему наши разработчики направляют свои усилия) пытаются создавать торговые алгоритмы, где, как правило, пестрит одна математика, то все это выливается один большой и неповоротливый монстр с единственным вопросом у создателя - "И что же дальше?".

пятница, 12 ноября 2010 г.

Почему лучше готовое, чем свое

Прислали мне ссылку на платформу собственного изобретения. Отвечу честно приславшему, в детали не вдавался, потому что там прогресса как такового практически нет. Но сразу вспомнилась картинка (cорри за мат, но из песни слов не выкинешь):


Или роботы, или своя платформа. Я уже сам стал замечать, какое сильное влияение оказал на мое личное время S#.

вторник, 21 сентября 2010 г.

Quik2Quant 1.0 beta release!

Полнофункциональный адаптер, обеспечивающий абсолютную интеграцию ИТС QUIK и последней версии передовой программы квантового анализа OpenQuant 2.9.7. Такая связка позволяет обеспечить полный комплекс решений на фондовом рынке, включая, но не ограничиваясь:
  • тестирование торговых стратегий на исторических данных;
  • реализацию любых в том числе самых изощренных торговых стратегий;
  • мгновенное получение любой необходимой информации из ИТС QUIK;
  • накопление и хранение информации о состоянии стаканов, котировок и сделок по множеству инструментов в режиме реального времени;
  • исполнение ваших стратегий в режиме реального времени;
  • отсутствие задержек в выставлении/снятии заявок;
  • контроль текущей позиции, изменения позиции, частичного исполнения, снятия заявки, качества исполнения;
  • … 
Интеграция OpenQuant и QUIK основана на событийной модели рынка и обеспечивает возможности быстрого создания и изменения торговых роботов, работу на любом таймфрейме и инструменте.
Решение, в настоящее время, не имеет аналогов на российском рынке и предоставляет неоспоримые преимущества создателям механических торговых систем высокого уровня.

Главное окно программы выглядит следующим образом:

В этом окне мы можем получить любую необходимую рыночую информацию из терминала QUIK. Однако самую большую ценность представляют иные возможности OpenQuant, которые делают его практически универсальным продуктом для создания роботов. Итак
1. График сделок по SRZ0 (1min) - встроенная стратегия SMA Crossover:

2. Ордера по стратегии и результаты их исполнения:

3. Контроль состояния счета в режиме он-лайн:

И это еще малая толика всех возможностей OpenQuant и QUIK. Более подробно с программой и предлагаемыми решениями можно ознакомиться тут & там
Посмотреть обучающее видео, чтобы узнать еще больше можно тут
Поинтересоваться как начать использовать продукт можно здесь.

суббота, 18 сентября 2010 г.

S# исполнился один год

Неожиданно подкралась особенная для меня дата - 18 сентября. Ровно год назад стартовал проект под названием S#. Правда, тогда он еще не назывался таким звучным для .NET именем. Но отсчет предпочитаю вести именно с этой даты.

За прошедший год было сделано довольно много работы. Во-первых, для Quik S# стал самой мощной платформой для разработки роботов. Ни один из аналогичных продуктов не имеет столько обширного функционала как S#. Во-вторых, S# стал поддерживать платформу SmartCOM, которая за последнее время стала набирать обороты. В-третьих, S# вырос из простой обертки над торговыми шлюзами, и стал предоставлять свои реализации некоторых алгоритмов.

И так, S# уже год как гордо шагает по России. Уже год, но все же находятся трейдеры, которые уверяют - проект завтра умрет, и его страшно использовать. Другие уверяют наоборот - следующий релиз станет коммерческим, поэтому начинают изобретать свой велосипед. Господа, так куда мне двигаться? =)

Вопрос, конечно же, риторический. Потому что на него я знаю четкие ответы. Более того, уже сейчас есть параллельно нескольких проектов (увы, пока не в публике), которые в скором времени еще более подстегнут интерес перейти на S# как можно быстрее. Потому что S# - не на сегодня и не на завтра. Он на российском рынке надолго. И в каждой новой версией будет предлагать все больше и больше возможностей.

Как я недавно заметил на СтокПортале, роботоводы - это некий элитарный клуб трейдеров среди обычных частников. В него всех подряд с улицы не пускают. Система безопасности проста - сложность в построении роботов. Можешь написать робота - проходи. Не можешь - извини =)

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

С появлением S# эта картина стала меняться. Начинающие роботоводы автоматически получают технологические преимущества, которых не было у их предшественников. Далее, кто решил остаться на своих решениях, с новой версией S# теряют свой первоначальный отрыв. И тот самый элитарный клуб становится доступным практически всем, кто прилагает усилия в разработке роботов.

В качестве заключения я хочу еще раз повторить посыл ко всей трейдерской публике, занимающейся торговыми роботами. Если у вас есть возможность и вы все еще думаете, переходить на S# или нет - переходите. Потому что дальше будет только круче, и вы просто не успеет за своими коллегами, которые уже это сделали. Ушел праздновать.

понедельник, 13 сентября 2010 г.

Сравнение TOP5 API для роботов.

Наконец, выпустил новый релиз S#, и настало время для написания беллетристики. Я уже писал подобные заметки о том, для чего нужен робот, чем он может пригодится вообще. Теперь я решил написать о том, какой API лучше выбрать для робота. Заметьте, именно для тех, кто пишет (+ собрался писать) на API, а не использует ТА программы. О последних и так достаточно написано и без меня.

Я сознательно не пишу данный пост для тех, кто программирует на S#. А для тех, кто любит самостоятельно вникнуть в проблемы системного программирования (именно системного, потому что разбираться, скажем, с TRANS2QUIK.dll это вовсе не программирование робота, как многие думают =) ). Конечно, мне до сих пор не понятно, как людям не жаль своего времени, но я хочу поделиться и с ними своим опытом работы (пусть даже с готовым решением).

И так, сравнение будет производиться между следующими API:
  1. Quik API
  2. SmartCOM
  3. Alfa Direct
  4. Alor COM
  5. Plaza2
.... и по следующим категориям:
  1. Сложность освоения
  2. Полнота данных
  3. Поддержка
  4. Распространенность
  5. Уровень документации
  6. Стабильность и ошибки
Все нижеописанное - мое личное мнение, основанное на использовании всех этих продуктов. Подчеркиваю, я не являюсь сторонником какой-то одной из API, и старался сделать вывод независимым.

И так, сначала опишу вкратце основные черты каждой из API.
  1. Quik API. По определению - это trans2quik.dll. По факту, это еще и собственный DDE сервер. Все потому, что обратная связь через API практически отсутствует. Приходится делать ну очень много работы. Поддержка отвечает стабильно, по плану. Документация сносная.
  2. SmartCOM. Ребята стараются, делают, но пока все плохо. Плохо в плане стабильности. Документация лучше, чем у Квика, да и использование много проще. Но вот данных - просто не достаточно. Если писать робота, нужно использовать внешние источники. Поддержка - самая лучшая.
  3. Alfa Direct. Похож на SmartCOM, только работает значительно стабильнее. Но. Поддержка отсутствует вообще как таковая. Я бы сказал, на любителей.
  4. Alor COM. Разобраться очень сложно. Пожалуй, сложнее только Plaza2. Документация нормальная (при таком запутанном API это большой плюс). Поддержка еле живая. Летом ее не было вообще.
  5. Plaza2. Такое же запутанное API как у Alor, только еще плюс к тому, что через данный API нужно посылать еще и специальные сообщения. Количество параметров компилятором не ограничивается, поэтому получается некий квест с разбором документаций (а их читать надо сразу как минимум две). Думаю, если нет хотя бы пару лет в программировании, можно даже в эту сторону не смотреть. Поддержка хорошая.

Получившаяся итоговая таблица (отмечал как с школе советских времен - от 1 до 5):

Quik SmartCOM Alfa Direct Alor COM Plaza2
Сложность освоения45321
Полнота данных51445
Поддержка45124
Распространенность53221
Уровень документации35432
Стабильность и ошибки41335
Итог2520171618

Я не удивлен полученным двум лидерам. Они вечно дышат друг другу в спину. Но и какого-то явного отрыва от других API не видно. Рынок постоянно будет модернизироваться, брокера предлагать все больше своих услуг, и все эти цифры будут стремиться к одному общему числу.

Вместо заключения хочу отметить, что в этой таблице все-таки нужно смотреть не на итоговые значение, а как конкретные цифры. Скажем, Alfa победила Alor. Но, если вы новичок, то из-за пункта "поддержка" вам путь заказан. Или другой вариант. Вы, наоборот, профи. Тогда при всей своей усредненности можно попробовать и Plaza2. Или, если взять мой жизненный пример, я не смог написать один из своих роботов на SmartCOM, потому что по нему невозможно было получить необходимые данные по опционным контрактам.

Дерзайте!

воскресенье, 25 июля 2010 г.

Марафон трейдера Дмитрия Барановского

Прочитал заметку создателя портала 2stocks.ru (бывший stockportal.ru) Барановский Дмитрий.

Заметка интересная, хотя жизненные истории таких людей всегда интересно читать. Некоторые моменты, конечно, не совсем правильны на мой взгляд. Но, что самое для меня главное было написано - это заключение. Дмитрий решил податься в роботоводы. Из заметки это видится как внезапное решение. И, я думаю, это не совсем так. Все же был какой-то длинный путь, чтобы точно прийти к моменту создания робота. Например, советники, индикаторы и т.д. Потому что, если решение было молниеносно... Чтож, я уже писал достаточно про негативные стороны торговых роботов. А пока можно только поздравить с правильным, на мой взгляд, решением трейдера такого уровня.

понедельник, 12 июля 2010 г.

Язык программирования для роботов

Прислали мне ссылки - http://www.quik.ru/forum/expert/57093/57093/ и http://quik.ru/forum/expert/57323/57323/. Прочитал, местами было интересно.

Я уже писал до этого о целесообразности в роботах вообще.
Теперь напишу, какой язык бы я выбрал вообще.

Понятно, что для себя я этот вопрос решил давно. Но для тех, кто только начинает разработку роботов, могу дать совет:

  1. Если давно используете какую-то систему Тех Анализа, то продолжайте писать на том языке, что там присутствует.
  2. Если решили написать робота в виде отдельной программы, выбирайте тот, что популярнее для алго трейдинга. А понять, какой именно язык самый-самый на российском рынке очень просто - по поддержке от вендоров. Возьмем китов: Quik, ИТ Инвест, Алор, Альфа Директ и NetInvestor:

    • Quik - для TRANS2QUIK.dll имеет два примера: один на C#, другой на C++.
    • ИТ Инвест - для SmartCOM имеет один пример на C#, документация так же написана с применением этого языка.
    • Алор - для Алор Трейд с COM объектами имеет один пример на C++, другой на C#.
    • Альфа Директ - для API имеет один пример на C#, один на Dephi, один на C++. Документация на C++, C#, VB, Delphi.
    • NetInvestor - для NIAPI имеет два примера: один на C#, другой на C++. Руководство пользователя - на C#.

    Итого (один бал за документацию, один за пример):

    • C# - 8 = 1 + 2 + 1 + 2 + 2
    • C++ - 5 = 1 + 1 + 2 + 1
    • Dephi - 2 = 2
    • VB - 1


Теперь о быстроте C++, которая была упомянута в тех ссылках. Как правильно заметили в той переписке, быстрота необходима для High Frequency Trading. Ни один из выше приведенных вендоров не дает такую пропускную способность, которые бы удовлетворяла подобному типу роботостроения. Дополнительно, это масштаб крупных игроков, которые могут позволить не только прямой доступ к бирже, но так же хостинг своих серверов на биржевых площадках. Для частников, в скорости С++ не даст никаких преимуществ. Минусов, особенной не для программистов (а трейдеры не занимаются программирование углубленно), очень много. И сложность языка, и чувствительность к ошибкам, и сложность в отладке и поиске ошибок... Море. Я писал на этом языке. Ничуть не огорчен, что ушел от разработки на С++. А как показывает тенденция софтверных гигантов, от C++ отказываются все больше и больше компаний.

К чему ведет популярность? Популярность ведет к тому, что данный язык становиться основным для разработки, под него увеличивается комьюнити, появляются решения сторонних разработчиков... Вообщем, бенефитов много.

А теперь вопрос, как же на западе? А на западе все давно решено: WealthLab, QuantDevelop, OpenQuant, RightEdge - все они поддерживают C#.

Остались вопросы с тем, какой язык необходимо выбирать?

понедельник, 29 марта 2010 г.

Для чего же нужен робот

Прочитав (и отписав, куда ж я без своего мнения) топики http://www.stockportal.ru/forum/index.php?showtopic=12851 и http://quoteforum.ru/index.php?showtopic=4190 (последний выглядит как жуткий стеб, так что воспринимайте данный топик с некой щепоткой скептицизма), я пришел в выводу, что роботы в торговле на российском рынке еще долгое время не смогут конкурировать с людьми.

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

  1. Отсутствие эмоционального напряжения.
  2. Возможность освободить себя от торговли, отдав всю работу роботу.
  3. Увеличить доход путем увеличения количества сделок.
  4. Об этом говорят многие, уже есть и компании предлагающие свою услуги по автоматизации. Значит это популярно, а популярность не растет на пустом месте.

Видите уже себя? Ага, а теперь вот мое мнение на эти четыре пункта - ПОЛНАЯ БРЕХНЯ:

  1. Тоесть, себе вы доверить не можете торговлю, а роботу да? С учетом того, что робот торгует или с ошибками (если самописный), или с непонятной порой логикой (если купленный, особенно когда он разработан не профессиональными командами, а форумными завсегдатаями). Робот, чем у него сложнее логика и чем он быстродейственней (а в другом случае и создавать нет причин программу), требует все больше и больше внимания. И я сильно сомневаюсь, что видя, как робот начинает медленно сливать, вы не потянитесь в заветной кнопке Стоп.

  2. Прочитали первый пункт? Ну и как, готовы освободить себя, уйдя, допустим в магазин за покупками, вместо сидения за монитором? Это в лучшем случае, если при случившемся изменении на рынке робот просто выкинет ошибку и прекратит свою работу. В худшем - продолжит торговать дальше. И такое он вам наторгует...

  3. Делая 10 сделок за день, я получаю X денег. Делая 10 * 100 сделок в день я буду получать в 1000 раз больше. Логично с математической точки зрения. А вот в реальности или заплатите еще и за комиссию, или получите те же X денег.

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

    Допустим, вы успешно пройдете путь создания своего робота, и в итоге получите ожидаемое. ВНИМАНИЕ, это еще не значит, что данный продукт принесет автоматически профит. Людям из компаний-разработчиков не интересны ваши гениальные стратегии, не приносящие ничего, кроме убытков. Им интересны ваш деньги, которыми вы будете оплачивать их жизнь.

    Очень, очень сложно грамотно поставить процесс, и получить действительно полезную вещь. Вот вам ссылка на мое обсуждение - http://forex.kbpauk.ru/showflat.php/Cat/0/Number/289931/an/0/page/0#Post289931 (читать с поста Bell-а, к слову. "нанять программеров" забавная тема).

    Если Вы захотели купить готового робота, то вот вам простое замечание. Стоящую стратегию никто вам продавать не будет (возможно, есть и исключения, но я их не встречал). Это если действительно ноу-хау, которое приносит деньги. А если и будут продавать, то это или ненужная разработка с сомнительным профитом, или обычная вспомогательная утилита, например, как привод. Кстати, последний может быть и полезен, но только это нисколько не робот, а лишь удобное расширение вашего терминала.

А теперь мое имхо, для чего нужно переводить торговлю на автоматизацию:

  1. Торговую стратегию невозможно реализовать ручным трейдингом. Например, высокочастотный трейдинг, сложный аналитический процесс и т.д.

  2. Минимизировать человеческий фактор. Например, когда идет с высокой частотой рутинная работа с копированием и вставкой параметров из одной программы в другую программу (например, одна вычисляет по формулам значения, другая по этим значениям и рынку анализирует, что сейчас необходимо делать).

Как видно из моих причин, все они исходят от одного слова - «Надо». В отличие от тех самых первых причин, ведущих свое происхождение от слова «Хочу». Уже видна разница: «Хочу» и «Надо».

Итог. Когда вы почувствовали, что вот оно, желание автоматизировать, в первую очередь задайте себе вопрос, а действительно ли оно «Необходимо», или же вам просто «Хочется» попробовать, не зная четко преимуществ в результате, как и за счет чего они будут достигнуты.

суббота, 12 декабря 2009 г.

Ecng.Trading 1.4

Обновление! Выложил новую версию 1.4.1

В новой версии (скачивать отсюда) появились стоп-заявки. Вернее, они были и до этого, но не существовала их полная поддержка: отсутствовал функционал по экспорту через DDE, не было возможности отменять и снимать стоп-заявки. Теперь все это есть:

1. Стоп-заявки регистрируются, изменяются и снимаются через те же методы (здесь и далее будет идти речь об интерфейсе ITrader), что и обычные: RegisterOrder, ReRegisterOrder и CancelOrder.
2. Чтобы получить все стоп-заявки, можно вызвать свойство StopOrders. В принципе, можно это сделать и через свойство Orders, где хранятся как обычные, так и стоп-заявки. Но в этом случае придется отфильтровывать самостоятельно.
3. События NewStopOrders и ChangedStopOrders вызываются при появлении новых стоп-заявок, или когда они изменяются (активизируются, снимаются).
4. Метод GetDerivedOrder позволяет получить заявку, которая была создана стоп-заявкой (вызывать можно только для тех стоп-заявок, для которых Order.DerivedOrderId не равен null). Производная заявка появляется в системе тогда, когда активизируется стоп. Метод полезен тогда, когда необходимо узнать, какие из сделок были созданы в рамках стоп-заявки. Напрямую это узнать невозможно, так как стоп-заявки не существуют физически на биржах, и есть только связь между обычной заявкой и сделкой.

Традиционно, скриншоты с изменениями DDE (коснулось не только таблицы стоп-заявок, но и обычных):



Обновленный info.wnd файл лежит в архиве.

Как создавать и работать со стоп-заявками, я показал с своем примере, который расширил функционально:



Изменения коснулись и алгоритма котирования, который появился в версии 1.3 под названием MarketOrderRegistry. Идея мне понравилась, а вот реализация нет. Да так, что хотелось вырвать из блога пост и бросить его в печку. Что не понравилось и что переделал:

1. Название MarketOrderRegistry не отражает саму идею котирование. Поэтому теперь класс называется QuotingAlgo.
2. Котирование происходило только в одном режиме - рыночная цена. Теперь их четыре: по рыночной цене (причем эта опция так же разбивается на три под-опции), по последней сделке, по лучше цене, по лучшему объему. За подробностями в документацию по QuotingTypes.
3. Не была сделана парадигма торговых заданий, которую я придерживаюсь с самого начала. Теперь все задания котирования выделены отдельным классом QuotingTask. И этих самых тасков (=заданий) можно создавать неограниченное количество.

понедельник, 30 ноября 2009 г.

Ecng.Trading 1.3

Выложил новую версию Ecng.Trading v1.3. Скачивать отсюда. Теперь по этой ссылке я буду выкладывать все новые релизы.

В новой версии я добавил два, на мой взгляд, главных изменения.

Первое касается того, как экспортировать произвольные таблицы из Квика. В QuikTrader появилось событие ProcessDdeData. Данное событие вызывается тогда, когда Квик послал DDE данные, которые QuikTrader не умеет обрабатывать. В качестве демонстрации я добавил в свое приложением-пример отображение данных по портфелю. Сначала я настроил Квик, добавив в него соответствующую таблицу:



Обновленные info.wld файл идет вместе с архивом.

Затем, добавил в него код обработки и отображения данных:

_trader.ProcessDdeData += (name, rows) =>
{
// узнаем, что пришедшие данные отвечают за портфель
if (string.Compare(name, "portfolio", true) == 0)
{
foreach (var row in rows)
{
var client = (string)row[0];
var portfolio = _portfolioWindow.Portfolios.FirstOrDefault(p => p.Client == client);

if (portfolio == null)
{
portfolio = new Portfolio { Client = client };
_portfolioWindow.Portfolios.Add(portfolio);
}

portfolio.Shorts = (double)row[1];
portfolio.Longs = (double)row[2];
portfolio.Collateral = (double)row[3];
portfolio.Margin = (double)row[4];
portfolio.Money = (double)row[5];
portfolio.PnL = (double)row[6];
}
}
};

Так как QuikTrader уже содержит методы по запуску и остановке DDE экспорта (StartDde и StopDde), то для удобства я перегрузил этим методы, чтобы они могли принимать имя экспортируемой таблицы (имя отображается в заголовке таблицы в Квике). Это позволит не только управлять своим потоком данных, но еще и запускать и останавливать его. Так что, если кто-то еще разрабатывает роботов под Excel, руководствуясь тем, что в него можно передавать данные как угодно, знайте, теперь это можно делать и в Ecng.Trading. Ну, а про преимущества разработки роботов на C# по сравнению с Excel я уже писал здесь.

Второе изменение знаковое. Наконец-то, в Ecng.Trading появился первый торговый алгоритм - котирование заявок. Например, необходимо срочно закрыть позицию, продав или купив по рынку (при минимуме потере профита). При высоколиквидном инструменте посланная из Квика или робота заявка может дойти до рынка уже "неактуальной" (в принципе, можно выставлять и из Квика рыночную заявку, но она работает не на всех биржах). Чтобы решить эту проблему, я написал класс MarketOrderRegistry, в который добавляется заявка. Заявка может быть и как уже ранее зарегистрированная, так и "пустая" (только что созданная и еще не выпущенная на биржу). И уже этот класс двигает эту заявку в стакане так, чтобы продать ее по выгодной рыночной цене. Рыночная цена опирается на текущий BestBid и BestAsk инструмента. Если же задана MarketDelta (передается в метод AddOrder), то цена заявки будет высчитываться как смещение цены последней сделки на эту самую MarketDelta.

Другое применения MarketOrderRegistry - это скальперская стратегия. Класс может сам создавать заявки и контролировать их в стакане.

Сам по себе класс MarketOrderRegistry построен на основе методов из класса TraderHelper:

1. GuarantyCancelOrder - гарантированно отменить заявку. В цикле посылает команду CancelOrder до тех пор, пока заявка не снимется (или не исполниться, если робот не успел снять).
2. ReRegisterOrder - перерегистрировать заявку. Удобен тем, что умеет подстраиваться под особенности биржи. Например, FORTS умеет изменять заявки одной транзакцией. Тогда в метод нужно передавать параметр isForts равный true. Если биржа не поддерживает изменения заявки одной транзакцией, то метод последовательно сначала снимает заявку через GuarantyCancelOrder, а затем регистрирует новую.

В принципе, можно реализовать своего собственного котировщика, вызывая методы TraderHelper. Как я уже упоминал, для той же скальперской стратегии. Сам по себе MarketOrderRegistry не смотрит на то, действительно ли нужно переставлять заявку. Он лишь старается выставить ее на край спреда. Поэтому, низкоуровневый класс TraderHelper для тех, кто реализует скальпинг, будет более полезен, чем сам MarketOrderRegistry. Используя TraderHelper можно написать логику лучше заявки (например, основываясь на ценовом или количественном объеме впереди в стакане).

воскресенье, 15 ноября 2009 г.

Ecng.Trading v1.2

Обновление! Рекомендую после данного сообщения прочитать это.

Руки окончательно дошли не только до Ecng.Trading, чтобы его расширить, но и выложить в общий доступ. Качайте. Самое главное изменение в этой версии - появились новые свечки. Раньше были свечки, основанные только на тайм-фрейме, причем, жестко определенном: минутка, пяти-, и т.д.. Теперь тайм-фрейм можно задавать любой, через .NET класс TimeSpan (например, TimeSpan.FromMinutes(2) создает двухминутку). И свечки стали вида:

1. TimeFrameCandle - старая добрая тайм-фрейм свечка.
2. TickCandle - свечка, строящаяся на основе количества сделок.
3. VolumeCandle - свечка, строящаяся на основе допустимого объема.
4. RangeCandle - свечка, строящаяся на основе максимального отклонения цены сделки от открытия свечки.

Для свечек я добавил два события в ITrader: NewCandle (вызывается для свечек, которые только что начали формировать), CandlesChanged (вызывается для измененных свечек).

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

1. RegisterTimeFrameCandles - передается инструмент, и нужный тайм-фрейм. После вызова этого метода, робот начнет получать события NewCandle и CandlesChanged с объектами TimeFrameCandle.
2. RegisterTickCandles - то же самое, что и RegisterTimeFrameCandles, только уже для свечек TickCandle.
3. RegisterVolumeCandles - аналогично.
4. RegisterRangeCandles - аналогично.

И последнее, немаловажное изменение, касается времени последней сделки (я уже писал об этом, пункт 2). Теперь, QuikWrapper принимает по DDE сразу два параметра, "Время последней сделки" и "Время изменения". Вот как выглядит теперь таблица инструментов:



Все скриншоты настроек DDE и файл с настройка окон в Квике я выложил в том же архиве.