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


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

Решение:

Пусть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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