Добрый день!
     Прошел почти год с момента моего предыдущего поста, хочу поделиться изменениями своего «приложения», произошедшими за этот период.
Несмотря на то, что предыдущая версия работала, несколько смущала производительность при приближении к дате экспирации, но, в тоже время, не хотелось все менять, т.к. был риск, что тождественность данных нарушится (в итоге статистика будет нерелевантна). Но все-таки собрался и пару месяцев назад переписал весь код с нуля (путем многократных тестовых запусков старой версии и новой, убедился в их преемственности и на серию (июнь) полностью перешел на обновленную версию). Основные изменения следующие:
     1. Переписан алгоритм определения волатильностей ТЦ, спроса, предложения
     2. Переход на явное определение всех переменных и упор на работу с массивами
     3. Изменен алгоритм протоколирования данных
     4. Ввод и вывод значений диапазоном
     5. Изменен алгоритм определения исходных данных для статистики

     В итоге производительность выросла в разы, если ранее средний расчет (за 1 квант времени) происходил за 0.5-1 секунды, пиковые (при протоколировании) от 3 сек до 10 (в последние недели перед экспирацией) секунд, то теперь средний расчет осуществляется менее чем за 0.1 секунды, пиковый до 0.3 секунд. Моделирование графиков PnL и грек занимает менее 0.2 сек, ранее это было около 3-4 секунд. И это далеко не предел, если минимизировать кол-во формул на листах, а их много (около 550) (закатать их в VBA) и минимизировать кол-во графиков (строить по требованию), то возможно добиться быстрых расчетов, но в целом этого и не надо. Загрузка процессора средняя, подвисаний (песочных часов), подтормаживаний экспорта нет, на этом же ноутбуке параллельно занимаюсь другими делами, ничего друг другу не мешает.
     Ниже привожу обновленную блок-схему моего приложения, и скриншоты основных листов (масштаб уменьшил, чтобы на 1 экран помещалось), чтобы было примерно понятно, что и как реализовано, и как все это выглядит. Общее кол-во строк кода на VBA 400 (немного, так как часть функциональности сделана функциями на самих листах).

( Читать дальше )

К посту Тимофея о конференции в Питере и выступлении на нем Григория Фишмана.  Публичные выступления у Григория есть..) Вот одно из них. Приятного просмотра.
 

В интеврью Илья рассказывает как превратил трейдинг в бизнес:



Напомню, что Илья также примет участие в конференции частных инвесторов в Санкт-Петербурге 5 апреля!
Запись в СПБ:
http://smart-lab.timepad.ru/event/100396/

Подошел к концу 1-й квартал этого года.
Можно подвести некие итоги. Не буду томить — итоги хорошие :)  +186% в целом по счетам.
 
Что было до этого:


( Читать дальше )

Сейчас улыбки RTS-6.14 на апрель и июнь выглядят так:
 
Если отнормировать эти улыбки (ln(K/S)/sqrt(T)) и пересчитать их с учетом оставшегося торгового времени, а не календарного, то у меня получается такая картинка:
 


( Читать дальше )

В продолжении утренней серии топиков по сложности алготрейдинга, хочу всем задать вопрос — КАК ОПРЕДЕЛИТЬ ФЛЭТ ПРОГРАМНО?

Это насущьный и актуальный вопрос не имеющий однозначного ответа. Выскажите свои мнения пожалуйста.

Итак, мы все понимаем что на рынке присутствуют только два состояния флэт и тренд. Определив алгоритм для распознания флэта и отфильтровав его мы получаем бесперебойный печатный станок. Кажется все просто, но на деле не совсем так. Ибо программно заложить алгоритм флэта не так то просто, приходится строить нейронно обучаемые цепочки, состоящие из логико — математических следований. Для построения этих цепочек требуются начальные вводные от количества и качества которых зависит точность работы основного алгоритма.

Итак как бы Вы определили флэт? На основании каких вводных Вы сможете предположить что в данный момент времени цена торгуется во флэте?

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

Я долго думал, как озаглавить данную заметку, в итоге получилось заглавие о сложности алгоритмизации. В общих чертах данная статья посвящена опыту проектирования торговой системы на одном известном паттерне «двойное дно», сложности его формализации и результатах тестировании на разных инструментах и таймфреймах.
Всё началось с того, что я со знакомым обсуждал рабочие паттерны на ликвидных инструментах. Это были самые простые и эффективные (как мы думали) – «пробой уровня», «отскок от уровня», «ретест уровня» (тест уровня с обратной стороны), «двойное дно» и т.д. В настоящей заметке речь пойдет как раз о «двойном дне», поскольку, с моей точки зрения, это наиболее редко используемый и упоминаемый паттерн: и я ни разу не видел, чтобы кто-то давал статистическую оценку по нему. К тому же у многих негативное отношение к данному паттерну, особенно если вспоминать поговорки про «покупку дна».
Хорошо бы определить, что мы будем понимать под «дном». Само дно хорошо видно постфактум (Рис. 1). Т.е. «дно» — это свечная фигура, после которой начинается рост. Это определение именно «дна», а не «ложного дна». Однако если дно на одном таймфрейме будет выглядеть именно как чёткая формация, то на другом таймфрейме этот паттерн может и не являться самым низким дном и после отскока (коррекции наверх) падение может продолжиться с образованием нового дна. Опять же дно бывает разное – дно как формация тестирования одного и того же уровня или повышающееся дно (Рис. 2), т.е. зарождение тренда. Как раз на втором типе я бы хотел остановиться.


( Читать дальше )

торгую аналогичным ботом 5 месяцев… решил сделать чуток получше… рисовал в тслабе кубиками где то месяц...
эквити результат форвардного теста… тест на постоянной сумме 3.5мио
средняя сделка +0.3% доходность где то 30-40% годовых...
идея была сделать бота нечувствительным к гэпам… и поиметь очень плавную эквити без дродаунов... 
торгую аналогичным ботом… очень приятные ощущения… жаль плечи порезали на споте в полную силу не поторговать… интересно что чем больше волатильность тем больше доходность… в 2008-09гг бот практически удвоился… всего один параметр оптимизации… бот юзает рыночный баг… достаточно сильную и стабильную неэфективность рынка… поэтому грааль я не спалю, это не паттерн — там самописный индикатор вычисляется... 
 
на самом деле это не лук, а все бумаги короткого списка доступные для шорта 12штук(газ лук рося втб сбер сберпр сурок фск русгидра урка транснефть татка)… всего тут 36 ботов… эта эквити суммарная
по-отдельность у каждого бота достаточно мерзкие эквити, и только суммарная от 36 ботов творит прям чудеса…
 
 
 

Прошедший 3 марта залив и постоянные зависания брокеров в момент сильных движений привели к мысли перейти на прямую работу с рыночными данными биржи.
В настоящий момент есть робот и библиотека под КВИК, в принципе несложно переписать модуль получения/отправки данных не на квик а на прямой шлюз, на верхнем уровне логики стратегий ничего не изменится.
Нужны фучи и опционы, желательно стакан и доска опционов.
Отправлять заявки и получать подтверждения о сделках.
С чего начать, что почитать, на какое API лучше заточиться?
Цель — минимизировать риски подвисания канала обмена данными с минимальными затратами.
Кто проделывал такой переход, поделитесь плиз основными тезисами.
Думаю многим будет интересно.

Всем привет. Если кто то пишет софт под квик подскажите. Кроме s# каким образом можно получать текущие цены из квика и отправлять, снимать заявки на с#.