Моделирование реквотов на тестере и анализ устойчивости советника

Введение

Встроенный в клиентский терминал Meta Trader 4 тестер стратегий - очень хороший инструмент верификации и оценки качества торговой стратегии, реализованной в советнике. Но у него на текущий момент есть две особенности, с моей точки зрения, довольно критичные. Во-первых, он не использует реальную историю тиков по инструменту, а моделирует их на основе минутных баров. Во-вторых, он не учитывает тот жизненный феномен, что брокеры довольно часто рекотируют, особенно на маленьких объемах сделок или на очень больших и на "тонком", низколиквидном рынке. Отсутствие возможности проверить своего эксперта в условиях возможных реквотов приводит к появлению "граалей", торгующих на шпильках, выбросах и нерыночных котировках. Уже не раз объяснялось и доказывалось, что подобная стратегия на реальном счете выигрышной быть не может, но, к сожалению, довольно часто бывает не до конца понятно, использует ли Ваш эксперт игру на "шпильках" или нет. На графике истории с наложенными на него сделками иногда можно видеть, что тестер открывает сделки на выбросах, но не всегда, и не ясно, сведет ли на нет стратегию реквотирования в эти моменты или же просто немного понизит прибыльность. В этой статье я изложу свой способ решения данной проблемы.

Допущения и определения необходимых понятий

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

Мы будем считать, что эксперт открывает и закрывает только ордера типа OP_SELL и OP_BUY. Сути это не меняет, но делает некоторые функции проще.

Моделирование реквотов в тестере стратегий

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

extern int RQF_TEST = 90;

Так как мы будем использовать функцию MathRand, возвращающую произвольное значение, хорошо было бы инициализировать последовательность псевдослучайных чисел. Для этого в начале работы эксперта будет выполняться функция MathSrand. Более подробно про генерацию случайных значений и то, зачем нужна эта функция, читайте в справочнике по языку MQL 4. Скажу только, что если MathSrand не использовать, то несмотря на "случаность" чисел из функции MathRand, при любом прогоне стратегии мы будем получать один и тот же результат. Чего, вообще говоря, нам не хочется:

int start()
  {
    //----
    MathSrand(TimeCurrent());

После этого нам надо написать собственные функции OrderSend и OrderClose. Назовем их MyOrderSend и MyOrderClose:

int MyOrderSend(int req_prob, string symbol, int cmd, double volume, double price, 
                int slippage, double stoploss, double takeprofit, 

                string comment="", int magic=0, datetime expiration=0, 
                color arrow_color=CLR_NONE)
  {
    if(IsTesting() && (MathRand() % 100) < req_prob && (cmd == OP_SELL || cmd == OP_BUY))
        return (-1); //modelling requote
    return(OrderSend(symbol, cmd, volume, price, slippage, stoploss, takeprofit, 
           comment, magic, expiration, arrow_color));
  }
 
bool MyOrderClose(int req_prob, int ticket, double lots, double price, int slippage,
                  color Color=CLR_NONE)
  {
    if(IsTesting() && (MathRand() % 100) < req_prob)
        return (false); //modelling requote
    return (OrderClose(ticket, lots, price, slippage, Color));
  }

Теперь все OrderSend и OrderClose функции в эксперте заменяем на MyOrderSend и MyOrderClose с указанием в качестве первого аргумента введенной ранее внешней переменной RQF_TEST. Ниже привожу пример из моего собственного эксперта.

OrderClose -> MyOrderClose:

if(MyOrderClose(RQF_TEST, ticket, amount, Bid, 0, Blue)) 
// PREV: if(OrderClose(ticket, amount, Bid, 0, Blue))
  {
    Print("Skalpel: Order #" + ticket + " closed! (BUY, " + Bid + ")");
            //... Something
  }
else
  {
    // Requote or something like this
    Print("Skalpel: Error while closing order #" + ticket + " (BUY)!");
    // ... Something
  }

OrderSend -> MyOrderSend:

ticket = MyOrderSend(RQF_TEST, Symbol(), OP_BUY, amount, Ask, 0, 
                     Bid-StopLoss*Point, Bid+TakeProfit*Point, 
                     NULL, EXPERT_MAGIC, 0, Blue);
// PREV: OrderSend(Symbol(), OP_BUY, amount, Ask, 0, Bid - StopLoss*Point, 
// Bid+TakeProfit*Point, NULL, EXPERT_MAGIC, 0, Blue);
 
if(ticket > 0)
    Print("Skalpel: Order #" + ticket + " opened! (BUY)");
else
    Print("Skalpel: Error while placing order."); 
    // ... Requote or something like this

Выводы и анализ результатов

Прежде всего требуется объяснить значение переменной RQF_TEST. Именно она задает количество реквотов на 100 трейдов и, соответственно, может принимать значения от 0, когда нет реквотов вообще, до 100, когда совершенно невозможно открыть или закрыть ордер. RQF_TEST равная 90, как в примере, означает, что из 100 попыток открыть или закрыть сделку примерно 90 окончатся неудачно, то есть будет смоделирован requote.

Собственно, результаты, полученные при различных значениях RQF_TEST и показывают устойчивость Вашей стратегии к реквотам и различиям в тиковом потоке от тестера и брокера.

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

В качестве примера привожу графики баланса классического эксперта, работающего на выбросах, при различных значениях RQF_TEST. Эксперт взят из статьи "Мой первый грааль" (http://articles.mql4.com/ru/articles/1413) и несколько переработан для наглядности. Все ордера типа limit реализованы через обычные рыночные, а также параметры подобраны таким образом, чтобы графики наиболее наглядно показывали ухудшение показателей при рекотировании.

Нет реквотов (RQF_TEST = 0):

В 90 случаях из 100 случается реквот (RQF_TEST = 90):

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

Замечания и дополнения

На самом деле довольно сложно найти советник, который бы становился из прибыльного убыточным из-за реквотов. Я довольно долго искал эксперта, у которого бы снижение качества наглядно показывал график баланса. Обычно рекотирование даже на уровне 50% резко снижает количество сделок и прибыль, при этом внешне график не меняя. Объяснение тут простое - если брокер Вам не дает открыть ордер на шпильке в 90 случаях из 100, то в оставшихся 10% ситуаций Вы все же получите несколько пипсов прибыли, да и то до тех пор, пока Вам не запретят использовать экспертов. Если помните, в статье "Мой первый грааль" описывались именно такие ситуации. Но даже если предположить, что брокер не будет мешать (что вряд ли), то уменьшение прибыли в 10 раз (а это именно такая цифра при рекотировании на уровне 90% - советник просто "пропускает" 90 шпилек из 100) лишает его всех прелестей "Грааля" - он будет менее прибыльным, нежели банковский вклад.