1. Вступ
2. механізація бектестінга
3. Торгові системи, засновані на перетинах двох мовного
4. Торгові системи, засновані на перетинах двох осциляторів
5. висновок

Вступ

Надійшла пропозиція від читача попередньої статті трохи механізувати сам процес бектестінга, щоб за один загальний візит можна було отримати результати всіх оптимізацій одночасно. Та й весь час пересувати період тестування в бектестінга теж не так щоб і дуже зручно, краще це якось зробити в автопілотні режимі. Сама ідея просто чудова - благо можливостей для її реалізації в MQL4 більш ніж достатньо, так що з вирішення цього завдання я і почну цю статтю.

механізація бектестінга

Для вирішення цього завдання слід:

1. Вписати під шапкою будь-якого, що цікавить вас експерта рядок такого змісту:

За допомогою цієї директиви ми включаємо в код експерта функцію IsBackTestingTime (). Цілком природно слід не забути помістити файл IsBackTestingTime.mqh в папку INCLUDE. Ця функція:

призначена для визначення часу, протягом якого відбувається бектестерная оптимізація або бектестінга. У ці періоди часу ця функція завжди повертає true, в решту часу ця функція повертає false. Крім цієї функції в код експерта цією директивою додаються зовнішні експертні змінні:

Я сподіваюся, що зміст цих змінних буде абсолютно зрозумілий всім, хто читав мою попередню статтю , І пояснювати їх зміст вдруге дещо зайве!

2. У блок стартовою функції перед кодом експерта необхідно помістити найпростіший універсальний код звернення до функції IsBackTestingTime (), що обмежує роботу експерта певними часовими рамками, в залежності від номера бектестерной оптимізації.

Схематично це буде виглядати наступним чином:

Кому интерсно рішення такого завдання на прикладі готового експерта, можуть подивитися код експерта Exp_5_1.mq4, що є модифікованим для бектестінга експертом Exp_5.mq4 з попередньої статті . За великим рахунком якоїсь значної різниці в оптимізації подібного експерта в порівнянні зі звичайним експертом немає. Хіба що, на мій погляд, не варто оптимізувати бектестерние змінні, за винятком змінної Opt_Number, хоча хтозна, тут у кожного свій підхід повинен бути.

Найголовніше не забувати, що після оптимізації при тестуванні ми отримуємо результати вже не всередині періоду оптимізації, а після нього, за правою границею! І все-таки робити все бектестерние оптимізації за один захід за допомогою генетичного алгоритму не зовсім зручніше, набагато цікавіше робити більш поглиблене дослідження кожної бектестерной оптимізації окремо без оптимізації вхідної змінної Opt_Number.

Але навіть в цьому випадку подібний підхід дуже сильно прискорює розуміння поведінки експерта. Ну і при подібному заході слід пам'ятати, що значення зовнішньої змінної Opt_Number може змінюватися від нуля і до деякого максимального значення, яке можна визначити наступним чином: від загальної періоду, на якому проводяться всі бектестерние оптимізації взятого в місцях, віднімається період бектестерной оптимізації в місцях ( Opt_Period) і віднімається період бектестінга (Test_Period). До отриманої величини додати одиницю. Отриманий результат і буде максимумом для змінної Opt_Number, в разі, якщо Period_Shift дорівнює одиниці.

Торгові системи, засновані на перетинах двох мовного

Цей варіант торгових систем досить поширений, і алгоритм, що лежить в їх основі давно слід було розглянути детальніше. Для довгих позицій алгоритм входу в ринок буде виглядати наступним чином:

Для коротких позицій алгоритм входу в ринок аналогічно буде таким:

В якості індикаторів можуть використовуватися два однакових мувинга з різними значеннями параметрів, що визначають усереднення в індикаторах. Передбачається, що параметр, що визначає усереднення у мувинга MovA має завжди менше значення, ніж цей же параметр у мувинга MovB. Таким чином мовного MovA виявляється у цій торговельній системі швидким мовного, а мовного MovB повільним. Ось варіант реалізації даної торгової системи на двох JMA мовного:

Торгові системи, засновані на перетинах двох осциляторів

Абсолютно аналогічно подібна торгова система може використовуватися не тільки з мовного, а й з осцилляторами, але в цій ситуації, як я вже писав в попередній статті , Виявляється при отриманні сигналів набагато логічніше не відразу входити в ринок, а ставити відкладені ордери. В якості самого наочного прикладу можна використовувати діаграму MACD.

Для виставлення відкладених ордерів BuyLimit алгоритм буде виглядати наступним чином:

Аналогічний алгоритм для ордерів типу SellLimit отримаємо в наступному вигляді:

Код цього експерта в чому аналогічний коду попереднього експерта:

висновок

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