робострой

Ровно год назад мы с моим другом и партнёром запустили на сервисе COMON FINAM алгоритмическую стратегию на ликвидных фьючерсах ABIGTRUST.

Результат впечатляет: +38% процентов годовых! И это при том, что начиная с ноября 2023 волатильность рынка снижалась и достигала своего исторического минимума, как писал в одном из своих постов Александр Горчаков (сторожила алгоритмической торговли в России). Напомню, что для большинства алгоритмов, в том числе для наших, высокая волатильность — это благо.

Результат нашей стратегии с «лихвой» уложился в прогнозные 65% при волатильности 45%, которые мы рассчитывали на исторических данных. По факту итоговая волатильность была существенно ниже. Поэтому в скором времени, мы пересчитаем прогнозные значения, и обновим информацию в описании к данной стратегии.

Также напомню, что алгоритм стратегии ABIGTRUST — это младший брат других алгоритмических комплексов, которые более требовательны к размеру капиталу, и которые мы ставим своим VIP клиентам с суммами от 10 миллионов рублей. В текущий момент мы совместно с одним из крупных профессиональных участников готовим продукт, который будет доступен более широкому кругу инвесторов (порог входа составит от 300 тысяч рублей) и очень надеемся, что он начнет свою работу уже в мае 2024. Анонс обязательно будет.

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

Уважаемый колега «Леха. Просто Леха» описал у себя в посте «Об упущенной прибыли...» его видение критериев определения суммы рискового капитала.
Я там прокомментировал (кратенько, строк на 20) свое мнение на этот счет. Здесь же предлагаю алгоритм расчета открытой позиции в моем боте.
Все числовые данные взяты «с потолка», ибо не важно конкретное значение, а токмо лишь правило вычисления.


Задача: определить допустимый предел максимальной открытой позиции, чтобы система имела минимальную вероятность попадания на «маржин-колл» или автоматическое сокращение позиции по параметру «Максимально допустимый текущий убыток», заложенный в системе; а также расчитать минимальный депозит (чистый денежный лимит), необходимый для непрерывных торгов.

Решение:

Пусть

x – открытая позиция, лот;

i – количество проигрышных входов в рынок;

D – размер денежного депо;

k – доля депо под «загрузкой» под открытые позиции;

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

     В предыдущем посте о бэк-тестировании были приведены основные контраргументы против использования тестирования торговых стратегий на исторических данных. Ну, или, по крайней мере, были высказаны весьма скептические мнения.

   Я не разделяю этого скепсиса.

  Итак, напомню несколько основных тезисов «против»:

• бэк-тесты не учитывают уровни ликвидности;
• сигналы на бэк-тестах не могут реализоваться в «боевых» условиях, потому что «рынок живой» (что это такое — каждый понимает по-своему);
• бэк-тесты не учитывают разных аварий на линии коммуникаций или сбоев торгового ПО;
• в реальности торговый алгоритм выдает одновременно 2 (!) торговых сигнала, робот-скотина «не фильтрует», а на бэк-тестах такого почему-то не бывает;
• колл-бэки «в реале» не отвечают так, как хотелось бы;
• бэк-тестирование — это удел презренных теоретиков и необстрелянных «окопников», никогда не бывавших в настоящем бою.

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

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

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

   Однако, как и следовало бы ожидать, некоторые не особо восхваляемые в приличном обществе личные качества комментаторов не дали этим «коллегам» возможности разглядеть предложенные возможности.
   Какие контраргументы предложили «коллеги» против бэк-тестирования?
   Увы, самые замшелые и незамысловатые, как-то:

• бэк-тесты не учитывают уровни ликвидности;
• сигналы на бэктестах не могут реализоваться в «боевых» условиях, потому что «рынок живой» (что это такое — каждый понимает по-своему);
• бэк-тесты не учитывают разных аварий на линии коммуникаций или сбоев торгового ПО;
• в реальности торговый алгоритм выдает одновременно 2 (!) торговых сигнала, робот-скотина «не фильтрует», а на бэк-тестах такого почему-то не бывает;
• колл-бэки «в реале» не отвечают так, как хотелось бы;
• бэк-тестирование — это удел презренных теоретиков и необстрелянных «окопников», никогда не бывавших в настоящем бою.

    Ну, и, естественно, еще многая многа чего невысказанного… Смысл только один: «все бэк-тесты — козлы, я один — Д'Артаньян».

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

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

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

Мой ответ (в 3-х частях, по мере внесения уточнений и подробностей) ему был следующий:

1. Все перечисленные «проблемы» решаются очень просто и успешно, если немного расширить само понятие «робот».
Добавьте надстройку, следящую за состоянием робота, за состоянием сети, инета, которая автоматически блокирует ненужные явления (задваивание ордеров на одном баре, например, или обрыв связи с сервером), и проблем не будет. Да, это выходит за рамки Lua (или того, на чем реализован робот). У меня такие сервисы реализованы на C#, опять же например. Итог: сам включается/выключается, «фильтрует базар» и поддерживает постоянное подключение, «постукивая» мне логами на почту или джаббер…



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

    На одном ресурсов оставил такой комментарий:

Как следует из аксиоматики матанализа, если решение устойчиво в пределах о(1), то это не означает, что оно потеряет устойчивость и на больших интервалах. Лишь бы для них, этих интервалов, так же существовало свое «О — малое». А значит, масштабирование возможно с высокой вероятностью. Нужно только определить доверительные интервалы цены и времени, в которых «О-малое» удовлетворяет Вашим понятиям о прибыли и доходности.

Так что каждый из участников ФР имеет шанс разработать стабильно зарабатывающую систему, если соразмерит свои аппетиты с этой самой величиной «О-малого».

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

FORTS
Кто поделится как можно выставить в Quik стоп-лимит который гарантированно сработает по рынку?
Если ставлю максимальную или минимальную цену, то такой стоп срабатывает нормально только в течении
текущей сессии. При смене границ коридора цен на следующий день может не сработать, а выдаст ошибку «Цена вне лимита».
На сайте Quik в форуме проблема обсуждалась но решения чего-то не вижу.
Вижу пока только вариант обрабатывать сообщение о цене вне лимита и выставлять заново с новой ценой.
Может кто знает решение получше?

Допустим есть стратегия с 2мя оптимизируемыми параметрами. При полном переборе например в Wealth Lab все результаты по профиту находятся в положительной зоне. Можно ли сказать что стратегия в реальных торгах чаще всего будет приносить прибыль? Тестирование за 3 последних года.

Если используются лимитные ордера, что еще кроме комиссии стоит учитывать?

Если я провожу тест на реальном стакане (ордер лог для qscalp) для более точной оценки результата и емкости стратегии, и результат получается лучше по профиту, значит ли это, что в реальных торгах результат будет так же лучше по сравнению с Wealth lab?

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

Предыстория:
В марте 2015 года я (в очередной раз) познакомился с торговлей на бирже.

В процессе освоения нашел на смартлабе описание и программу поиска графических паттернов Stock Pattern Viewer Алексея Ван. Основная идея в том, что программа ищет похожие свечные формации в истории. Спасибо автору за идею. Алгоритм создания паттернов описан сдесь

Немного владею Java. Поэтому написал свою программу которая нормально загружает/обновляет историю интересующего инструмента. И автоматически ищет свечные паттерны длинной от 1 свечи до сколько надо. У меня на истории 100 тысяч свечей я ограничиваю длинной до 15 свечей. После получения очередной свечи программа на основе хвоста истории создает 15 графических паттернов разной длинны, с вхождением образцов на графике для каждого паттерна не менее 2000 раз.

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