Отправлено: 10.11.14 19:27. Заголовок: Оценка торговой системы

Оценка торговой системы
Определение качества торговой системы на основе методики, предложенной Ван Тарпом. Идея подана здесь.

 Отправлено: 30.03.16 13:00. Заголовок: Scriptong пишет: Зд..

Scriptong пишет:

цитата:

Так он уже сделан. Достаточно перенести соответствующие функции из скрипта в OnTester.

Я имел ввиду его оформление в виде #include к Вашему стандартному набору библиотечных функций.

Scriptong пишет:

цитата:

Здесь не продумана простая вещь: перед открытием любого ордера свободные средства всегда больше, чем после его открытия. Поэтому, если в качестве критерия остановки прохода тестера использовать условие: Текущие свободные средства < Размер начальных свободных средств, то все проходы будут останавливаться сразу же после открытия первого ордера.

Сравнение идет на уменьшение свободных средств меньше размера начального депозита:
Было 500$:
если их слили на первом трейде - то и проверять нечего, тестер сам проверит
если наторговали 700, снова открылись, просадка + маржа стала > 500 - тогда прерываем проверку данного варианта.

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

Поэтому имеет смысл проверять все входы на соответствие начальным условиям торговли без просмотра глазами пункта статистики "Максимальная просадка" по каждой записи. Пусть тестер проверяет сам при оптимизации.

 Отправлено: 01.04.16 17:42. Заголовок: Genry пишет: Я имел..

Genry пишет:

цитата:

Я имел ввиду его оформление в виде #include к Вашему стандартному набору библиотечных функций.

К сожалению, это невозможно, т. к. необходим источник данных. А в разных вариантах использования он свой. Поэтому нужно реализовывать все это под каждую конкретную задачу: набрать нужные функции и вставить по месту, подключив требуемый источник данных (в данном случае историю сделок тестера).

Genry пишет:

цитата:

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

Тогда я не понимаю, причем здесь свободные средства? Подход то совершенно другой:

1. В OnInit() запомнить начальный баланс.
2. По ходу прогона постоянно вычислять максимальную просадку не по тому принципу, который использует тестер (максимальные средства - минимальные средства), а по принципу: максимальный баланс - минимальные средства.
3. Если максимальная просадка превысила начальный баланс, то прерывать тестирование.

цитата:

double g_startBalance, g_maxBalance; int OnInit() { g_startBalance = AccountBalance(); g_maxBalance = g_startBalance; } void OnTick() { g_maxBalance = MathMax(AccountBalance(), g_maxBalance); if (g_maxBalance - AccountEquity() > g_startBalance()) ExpertRemove(); }

 Отправлено: 02.04.16 09:54. Заголовок: Scriptong пишет: К..

Scriptong пишет:

цитата:

К сожалению, это невозможно, т. к. необходим источник данных. А в разных вариантах использования он свой. Поэтому нужно реализовывать все это под каждую конкретную задачу: набрать нужные функции и вставить по месту, подключив требуемый источник данных (в данном случае историю сделок тестера).

Жаль, я думал что статистики, предоставляемой оптимизатором https://docs.mql4.com/ru/constants/environment_state/statistics#enum_statistics,
хватит для обобщения метода расчета без привязки к конкретным данным.

Scriptong пишет:

цитата:

Тогда я не понимаю, причем здесь свободные средства? Подход то совершенно другой: 1. В OnInit() запомнить начальный баланс. 2. По ходу прогона постоянно вычислять максимальную просадку не по тому принципу, который использует тестер (максимальные средства - минимальные средства), а по принципу: максимальный баланс - минимальные средства. 3. Если максимальная просадка превысила начальный баланс, то прерывать тестирование.

Спасибо, попробую этот вариант

 Отправлено: 04.04.16 15:30. Заголовок: Genry пишет: Жаль, ..

Genry пишет:

цитата:

Жаль, я думал что статистики, предоставляемой оптимизатором https://docs.mql4.com/ru/constants/environment_state/statistics#enum_statistics, хватит для обобщения метода расчета без привязки к конкретным данным.

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

 Отправлено: 06.04.16 12:46. Заголовок: Scriptong пишет: То..

Scriptong пишет:

цитата:

Тогда я не понимаю, причем здесь свободные средства? Подход то совершенно другой: 1. В OnInit() запомнить начальный баланс. 2. По ходу прогона постоянно вычислять максимальную просадку не по тому принципу, который использует тестер (максимальные средства - минимальные средства), а по принципу: максимальный баланс - минимальные средства. 3. Если максимальная просадка превысила начальный баланс, то прерывать тестирование.

Genry пишет:

цитата:

Спасибо, попробую этот вариант

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

Вот результат работы алгоритма: AccountEquity еще в плюсе, а AccountFreeMargin уже в минусе и Stop Out наступил раньше чем
сработала проверка.

void OnTick()  
  {  
  g_maxBalance = MathMax(AccountBalance(), g_maxBalance);  
  if (g_maxBalance - AccountEquity() > g_startBalance)  
  ExpertRemove();  
  }

Alert: g_maxBalance=510.12 AccountEquity()=359.04 g_maxBalance - AccountEquity() =151.08 > g_startBalance=500
Alert: g_maxBalance=510.12 AccountFreeMargin=288.39
open #79 sell 0.04 EURUSD at 1.10410 ok

Alert: g_maxBalance=510.12 AccountEquity()=42.768 g_maxBalance - AccountEquity() =467.352 > g_startBalance=500
Alert: g_maxBalance=510.12 AccountFreeMargin=-101.81

Alert: g_maxBalance=510.12 AccountEquity()=41.488 g_maxBalance - AccountEquity() =468.632 > g_startBalance=500
Alert: g_maxBalance=510.12 AccountFreeMargin=-103.09

Alert: g_maxBalance=510.12 AccountEquity()=29.328 g_maxBalance - AccountEquity() =480.792 > g_startBalance=500
Alert: g_maxBalance=510.12 AccountFreeMargin=-113.97

2016.04.06 14:07:13.105 2015.09.10 01:51 stopped because of Stop Out

 Отправлено: 08.04.16 12:16. Заголовок: Genry пишет: Вот ре..

Genry пишет:

цитата:

Вот результат работы алгоритма: AccountEquity еще в плюсе, а AccountFreeMargin уже в минусе и Stop Out наступил раньше чем сработала проверка.

В этом примере нет пересидки просадки, а потому он не является проблемой. Напомню, задачу Вы формулировали так:

цитата:

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

Таким образом, решалась совершенно другая проблема, при которой тестер не останавливал проход оптимизатора, т. к. маржи хватало. В этом же примере, тестер сам остановил тестирование, т. к. в его ходе зафиксирован стоп аут. Следовательно все ОК.

 Отправлено: 08.04.16 13:21. Заголовок: Scriptong пишет: Та..

Scriptong пишет:

цитата:

Таким образом, решалась совершенно другая проблема, при которой тестер не останавливал проход оптимизатора, т. к. маржи хватало. В этом же примере, тестер сам остановил тестирование, т. к. в его ходе зафиксирован стоп аут. Следовательно все ОК.

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

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

Например, оптимизация была сделана для депозита в 500$ с 1 августа 2015 по 6 марта 2016, а потом полученный сет взял интервал с
01 декабря 2007 года по апрель 2016года. Пусть доход его небольшой, но он показал отличную живучесть для гридера с таким маленьким
депозитом.

 Отправлено: 08.04.16 16:02. Заголовок: Genry пишет: Даже е..

Genry пишет:

цитата:

Даже если сет вынырнул из этой ситуации, мы сразу зарубаем его и берем следующий.

Это довольно-таки редкий случай. Ведь речь идет о балансировании на краю пропасти - куда ветер подует, там и окажемся