алготрейдинг

Исходя из своего видения рынка, выбираем в настройке робота опционную конструкцию (ОК), кот. робот должен будет построить. При этом робот должен будет активно торговать на её составных частях и при этом должен поддерживать объёмы и пропорцию инструментов на страйках, используемых в ОК. В итоге, к экспирации мы должны подойти с выигрышной ОК и плюс с заработанным ТП от алгоритмической торговли.  Итак, задача робота соблюдать направление торговли для каждого страйка, а также определять допустимый диапазон объемов для каждого торгуемого страйка и поддерживать эти объемы в определенном соотношении. Предлагаю совместно реализовать эту и др. идеи, подробнее здесь roboforts.ru/forum/%D1%81%D0%BE%D0%B2%D0%BC%D0%B5%D1%81%D1%82%D0%BD%D1%8B%D0%B5-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8-%D1%82%D0%BE%D1%80%D0%B3%D0%BE%D0%B2%D1%8B%D1%85-%D1%80%D0%BE%D0%B1%D0%BE%D1%82%D0%BE%D0%B2-%D0%B4%D0%BB%D1%8F-quik.html

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

    Приведу пример нехорошего (иногда, говорят – с запашком) кода:

class Strategy
{
   public Strategy()
   {
     var mgr = new TestOrderManadger();
     mgr.PlaceOrder(...);
   }
}

     Здесь плохо то, что класс Strategy зависит от класса TestOrderManadger. В такой реализации нельзя начать использовать какой-нибудь другой менеджер заявок (AnotherOrderManadger) без перекомпиляции библиотеки с классом Strategy. Тем более тут нарушается принцип единства ответственности – класс Strategy, помимо своей прямой обязанности, также, создаёт внутри себя зависимости. Чтобы исправить ситуацию, можно использовать интерфейсы:

interface IOrderMandger
{
   void PlaceOrder();
}

class TestOrderManadger : IOrderMandger
{
   public void PlaceOrder(){}
}

class Strategy
{
   public Strategy(IOrderMandger orderMandger)
   {
     var mgr = orderMandger;
     mgr.PlaceOrder(...);
   }
}

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

У меня есть возможность ее роботизировать, но нет возможности протестировать на истории… Наверняка, кто-то это уже тестировал...

Сама идея:

1.Имеем, например, 500 тыс.руб. на брокерском счете.

2.На 200 тыс.руб. покупаем корзину ОФЗ из 6-10 выпусков.

3.Еще на 250 тыс.руб. покупаем, например, акции Газпрома по 125 руб. в количестве 2000 шт.

4.50 тыс.руб. (можно меньше) оставляем в кэше.

5.Если цена падает, то мы докупаем акции, чтобы акционная составляющая портфеля оставалась 250 тыс.руб..

6.Если цена растет, то продаем.

7.Шаг — 1 лот.

8.Портфель (задействованный на акции) при этом будет постоянно 250 тыс.руб.

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

10. Если заходим в маржу, то на следующий день продаем часть ОФЗ (благо, они торгуются Т+1).

11.Если скапливается лишний кэш, то покупаем ОФЗ или FXMM, не в этом основная суть.

Приветствую

Решил сделать маленький эксперимент, выделил субсчет с 20т.р Запустил пару алгоритмов чтобы посмотреть возможно ли хоть как либо раскачать счет. 

Спойлер — Нет/не интересно.

Итак, зачем эксперимент? Частенько сталкиваюсь с трейдерами с практически нулевыми счетами, которые хотят «попробовать себя» в трейдинге. Естественно это счета до 50т.р или уже частично слитые «депозиты».  Вспомнил себя, и как сам начинал торговать и сливал минимальные депо и подумал попробовать на минимальном счете поторговать. Допустим, изначально понимал, что расскачивать счет (в идеале) можно годами от такой стартовой цифры, и предположим я амбициозный трейдер, который хотел бы показать стабильность на рынке и привлечь постепенно внимание «инвесторов» или работодателя.

Конечно же гипотетически мой алгоритм должен был быть менее доработанный, и больше напоминать типовой алгоритм hi/low, но вновь представим, что трейдер весьма умен и применив знания, написал более менее похожий на адекватный, алгоритм. Счет маленький, всего 20т.р. и так как трейдер хочет привлечь внимание инвестора/работодателя, то он не торгует фьючерс на ртс от (греха подальше). Фактически получилось запустить 2 робота, которые торгуют 1-2 лота, тем самым в максимальной загрузке, алгоритм не использует полностью, доступное депо. 

Так вот, что получается:
Вначале скрины результатов скриптов на периоде с 21.09.2017 по текущий день 

и второй скрипт

     Привет всем! В предыдущем посте рассматривались два объекта, которые формируют закрытые позиции и считают статистику торговли (IClosePositionManager, IResultManager). Сегодняшняя статья будет посвящена визуализации этих данных и общей архитектуре торговой системы.

     В своё время я рассказывал про паттерн проектирования MVC, что логика должна быть отделена от визуализации, и ещё, что у каждой формы должен быть свой презентер. Также хотел отметить, что проект лучше разбивать на несколько логических модулей (библиотек классов в c#). Свой проект я разделил на: definitions – содержит базовые, ни от кого не зависящие классы, интерфейсы и описания, local – реализация интерфейсов для локального тестера, smartcom – реализация интерфейсов для коннектора, в данном случае смарткома, strategies – вынес в отдельный модуль все стратегии, UI – внешний интерфейс системы (формы и их презентеры) и т.д. В каждом таком модуле я обычно создаю ещё несколько папок – в модулеUI, например, есть папка interfaces, presenters и views.