Погрешности тестирования во время тестов в OsEngine и других платформах.

Погрешности тестирования во время тестов в OsEngine и других платформах.

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

Вы должны понимать, что любое тестирование имеет погрешность. Более того, погрешности эти в разных торговых платформах разные. Написав торгового робота в OsEngine, MT4, TsLab, мы рискуем получить совершенно разные итоговые результаты.

Что может рождать эту погрешность в тестах:

  • Торговая логика робота, генерирующая логические нонсенсы.
  • Условности в исполнении ордеров.
  • Данные для тестирования.
  • Методы работы модуля для тестирования (векторный/событийный).

Давайте об этом поговорим.

Торговая логика робота, генерирующая логические нонсенсы.

Рассмотрим сразу пример. Вводные:

  • Тестируем на часовых свечках.
  • Позиция открывается отложенным ордером типа BuyAtStop. То есть по пробою какого-то уровня.
  • В логике робота мы подписаны на событие открытия позиции.
  • В логике открытия позиции одновременно выставляем стоп и профит.

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

Что в примере будет происходить на самом деле:

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

 

ВАЖНО!

В данном примере, подписываясь на событие открытия позиции и выставляя в нём профит/стоп-приказы, для отсутствия погрешностей и логических ошибок тесты должны проводиться НА ТИКОВЫХ ДАННЫХ. Либо следует изменить Вашу логику, чтобы робот совершал какие-то действия с профитами и стопами по завершению свечи. Одновременно с этим выставлял ТОЛЬКО СТОП или ТОЛЬКО ПРОФИТ.

Логические нонсенсы – самое частое и опасное применение тестера/оптимизатора, которое только может быть. В рамках него, не разбираясь во внутреннем устройстве тестера, пользователь может себе прибыль НАРИСОВАТЬ.

Условности в исполнении ордеров.


Рис. 1. Настройки исполнения ордеров.

Лимитные ордеры в целом могут быть исполнены следующим образом:

  • По пересечению цены ордера с ценой инструмента.
  • По прикосновению цены ордера с ценой инструмента.
  • 50 на 50 %. Из первых двух вариантов делается исполнение сначала одним, потом другим способом.

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

  • По закрытию текущей свечи.
  • По открытию следующей свечи.
  • По цене самого маркет ордера без оглядки на цену свечей.

Данные для тестирования.

Свечи имеют в себе всего четыре значения. И если тесты идут на них, некоторые типы заявок на свечном тестировании вносят существенную долю ошибки:

  • Маркет ордера.
  • Стоп и профит ордера, выставленные одновременно.

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

  • Исполнение по трейдам, а не по стакану не даёт 100 % точности определения точки входа как в реале.
  • Тестирование больших объёмов данных за год, два или 10, невозможно или близко к невозможному. Что делает невозможными некоторые виды тестирования, такие как Walk-Forwards или Cross-Tests на достаточно глубоких данных, чтобы понять робастность стратегии.

Архитектура работы модуля для тестирования (векторный/событийный).

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

Особенности:

  • Скорость. Это в десятки раз быстрее событийной архитектуры.
  • Заглядывание в будущее. Пользователи Wealth-Lab про это десятки постов написали. Это страшная вещь при тестах на таком типе архитектур. Очень опасная.
  • Сложности при переносе в боевые торги, ибо логика робота не описывает их так, как это будет в реале.

Событийная архитектура тестирования – способ проведения тестов, когда создаётся, так называемый, эмулятор биржи. Он старается на основе имеющихся данных, выдавая их последовательно, сделать так, чтобы робот не понимал, торгует он в тестере или в реале.

Особенности:

  • Низкая скорость.
  • Отсутствие заглядывания в будущее.
  • Простота при переносе в боевые торги.

Так что же делать?

Принять эту данность как есть. Понимать, что погрешность в любом случае будет. И для массовых тестов всё равно придётся применять свечи, допуская, что результаты тестирования могут отличаться от того, что будет в реальности на какую-то погрешность.

12:24
741

Комментарии

Нет комментариев. Ваш будет первым!