Форум » Инструменты трейдера » Оценка торговой системы » Ответить
Оценка торговой системы
Scriptong: Оценка торговой системы Определение качества торговой системы на основе методики, предложенной Ван Тарпом. Идея подана здесь.
Ответов - 23, стр:
1 2 All
Genry: Scriptong пишет: Так он уже сделан. Достаточно перенести соответствующие функции из скрипта в OnTester. Я имел ввиду его оформление в виде #include к Вашему стандартному набору библиотечных функций. Scriptong пишет: Здесь не продумана простая вещь: перед открытием любого ордера свободные средства всегда больше, чем после его открытия. Поэтому, если в качестве критерия остановки прохода тестера использовать условие: Текущие свободные средства < Размер начальных свободных средств, то все проходы будут останавливаться сразу же после открытия первого ордера. Сравнение идет на уменьшение свободных средств меньше размера начального депозита: Было 500$: если их слили на первом трейде - то и проверять нечего, тестер сам проверит если наторговали 700, снова открылись, просадка + маржа стала > 500 - тогда прерываем проверку данного варианта. Смысл проверки - убедиться, что стратегия отработает правильно, если входить с начальными условиями на всем протяжении проверяемой истории. А то в результатах куча вариантов, когда первые трейды увеличили баланс таким образом что последующие просадки больше начального депозита ЕА успешно пересиживает. А в реале потом трейдер входит с этими параметрами и налетает на д.Колю. Поэтому имеет смысл проверять все входы на соответствие начальным условиям торговли без просмотра глазами пункта статистики "Максимальная просадка" по каждой записи. Пусть тестер проверяет сам при оптимизации.
Scriptong: 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(); }
Genry: Scriptong пишет: К сожалению, это невозможно, т. к. необходим источник данных. А в разных вариантах использования он свой. Поэтому нужно реализовывать все это под каждую конкретную задачу: набрать нужные функции и вставить по месту, подключив требуемый источник данных (в данном случае историю сделок тестера). Жаль, я думал что статистики, предоставляемой оптимизатором https://docs.mql4.com/ru/constants/environment_state/statistics#enum_statistics, хватит для обобщения метода расчета без привязки к конкретным данным. Scriptong пишет: Тогда я не понимаю, причем здесь свободные средства? Подход то совершенно другой: 1. В OnInit() запомнить начальный баланс. 2. По ходу прогона постоянно вычислять максимальную просадку не по тому принципу, который использует тестер (максимальные средства - минимальные средства), а по принципу: максимальный баланс - минимальные средства. 3. Если максимальная просадка превысила начальный баланс, то прерывать тестирование. Спасибо, попробую этот вариант
Scriptong: Genry пишет: Жаль, я думал что статистики, предоставляемой оптимизатором https://docs.mql4.com/ru/constants/environment_state/statistics#enum_statistics, хватит для обобщения метода расчета без привязки к конкретным данным. На самом деле так и есть. Я говорю о невозможности автоматического подключения источника данных. Его просто нужно указать и все. Для этой цели в скрипте все уже есть. Нужно лишь скопировать несколько функций в свой проект. Просто это решение не универсальное, т. к. в каком-нибудь другом случае потребуется немного иной набор функций.
Genry: Scriptong пишет: Тогда я не понимаю, причем здесь свободные средства? Подход то совершенно другой: 1. В OnInit() запомнить начальный баланс. 2. По ходу прогона постоянно вычислять максимальную просадку не по тому принципу, который использует тестер (максимальные средства - минимальные средства), а по принципу: максимальный баланс - минимальные средства. 3. Если максимальная просадка превысила начальный баланс, то прерывать тестирование. Genry пишет: Спасибо, попробую этот вариант Попробовал этот вариант расчета, он считает иначе, а нас при оптимизации интересует размер свободной маржи, который не должен быть меньше начального баланса. Вот результат работы алгоритма: AccountEquity еще в плюсе, а AccountFreeMargin уже в минусе и Stop Out наступил раньше чем сработала проверка. [pre2]void OnTick() { g_maxBalance = MathMax(AccountBalance(), g_maxBalance); if (g_maxBalance - AccountEquity() > g_startBalance) ExpertRemove(); }[/pre2] 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
Scriptong: Genry пишет: Вот результат работы алгоритма: AccountEquity еще в плюсе, а AccountFreeMargin уже в минусе и Stop Out наступил раньше чем сработала проверка. В этом примере нет пересидки просадки, а потому он не является проблемой. Напомню, задачу Вы формулировали так: А то в результатах куча вариантов, когда первые трейды увеличили баланс таким образом что последующие просадки больше начального депозита ЕА успешно пересиживает. А в реале потом трейдер входит с этими параметрами и налетает на д.Колю. Таким образом, решалась совершенно другая проблема, при которой тестер не останавливал проход оптимизатора, т. к. маржи хватало. В этом же примере, тестер сам остановил тестирование, т. к. в его ходе зафиксирован стоп аут. Следовательно все ОК.
Genry: Scriptong пишет: Таким образом, решалась совершенно другая проблема, при которой тестер не останавливал проход оптимизатора, т. к. маржи хватало. В этом же примере, тестер сам остановил тестирование, т. к. в его ходе зафиксирован стоп аут. Следовательно все ОК. Ок, понятно. Просто я ту-же логику применил к марже, а не к балансу. Если тестер фиксировал падение свободной маржи в объеме первоначального баланса - вариант отбрасывался. По сути: зачем нам торговый вариант в котором советник не может открывать сделки из-за отсутствия свободных средств? Даже если сет вынырнул из этой ситуации, мы сразу зарубаем его и берем следующий. Зато варианты прошедшие тест обладают приличной устойчивостью к разным передрягам и легко расширяют диапазон тестирования. Например, оптимизация была сделана для депозита в 500$ с 1 августа 2015 по 6 марта 2016, а потом полученный сет взял интервал с 01 декабря 2007 года по апрель 2016года. Пусть доход его небольшой, но он показал отличную живучесть для гридера с таким маленьким депозитом.
Scriptong: Genry пишет: Даже если сет вынырнул из этой ситуации, мы сразу зарубаем его и берем следующий. Это довольно-таки редкий случай. Ведь речь идет о балансировании на краю пропасти - куда ветер подует, там и окажемся
полная версия страницы