Алгоритм расчёта просадки, или Самостоятельная оценка результатов тестирования эксперта - страница 3

 
Прогнал советника на EURUSD H1 по Open Price, результаты не сошлись немного. Но нужно учитывать, что
  • при расчете просадок не учитываются свопы (расчет текущего эквити);ю
  • расчет просадок производится на минутках, и просадки считаются по экстремумам минутных баров, при этом считаются просадки и для минутных баров открытия и закрытия(нужно чуток точнее эти бары считать).
2007.12.25 10:20:33 2007.12.07 22:59 antikotov-online EURUSD, H1: AbsDD=259. 5 MoneyDrawDown=446 MoneyDrawDownInPercent=4.3783 RelativeDrawDown=4. 3783 RelativeDrawDownInMoney=446
Когда прогнал экпсерта также на EURUSD H1, но уже по Every Tick, то результаты стали уже ближе:
2007.12.25 10:26:23 2007.12.07 22:59 antikotov-online EURUSD, H1: AbsDD=264. 5 MoneyDrawDown=444. 5 MoneyDrawDownInPercent=4.3664 RelativeDrawDown=4. 3664 RelativeDrawDownInMoney=444. 5

А вот что показал тестер на Every Ticks




Дальнейшее уточнение алгоритма пока не входит в мои планы, мне кжается, что достигнутая точность удовлетворительна (на мой взгляд). Но до идеала при желании довести можно.
 
Спасибо за уделённое время и код. Вечером сделаю то же самое, проверю.

А почему стоит код проверки?
!IsOptimization())

Код startCalculate() не будет работать в режиме оптимизации, или это ограничение вида "мне не нужно было считать в оптимизации"?
 
Мне не нужно было считать при оптимизации. Я вставил строку в это блок, который уже был, и выбросил из него все остальное, когда писал сообщение на форуме. Можно и без проверки на оптимизацию.
 
Rosh писал(а) >>
Мне не нужно было считать при оптимизации. Я вставил строку в это блок, который уже был, и выбросил из него все остальное, когда писал сообщение на форуме. Можно и без проверки на оптимизацию.

А вот мне понадобилось считать просадку при оптимизации.

Подставил в deinit CalculateSummary.mq4, все работает, но просадка:

прибыль сд. просадка

1 53869 953 17213
2 49978 1345 9089
3 48101 1449 9089
4 47497 921 11612
5 44367 249 12917
6 37721 481 16634
7 33246 919 14631
8 33236 421 19448
9 32260 1265 17782
10 30766 267 11438

значительно отличается от рассчитанной тестером:

Подставил MAE_MFE_DrawDowns.mqh, значения просадок (брал MoneyDrawDown) те же, что

и в первой текстовой таблице. Но расчет очень замедляется (в код особо не вникал, запись

в файл отключал). Может алгоритмы со времени написания темы изменились? Тогда где взять

свежие?

Kind Regards!

 
Help me кто знает текущий алгоритм подсчета просадки в МТ4...
 
voltair писал(а) >>

Может алгоритмы со времени написания темы изменились? Тогда где взять

свежие?

Алгоритмы не изменились

 
stringo писал(а) >>

Алгоритмы не изменились

Почему же у меня расхождения?

Подставлял MaxDrawdown, AbsoluteDrawdown, RelDrawdown (из SummaryReport.mq4) - не помогает.

Так какая переменная дает ту просадку, которая отражается в тестере при оптимизации?

 
voltair >>:

Почему же у меня расхождения?

Просадку надо считать по Equity.

А для этого надо проводить нужные расчеты не один раз в конце работы (в deinit()-е), а на каждом тике (в start()-е).

Но работа замедляется, в принципе, не сильно.

 
komposter писал(а) >>

Просадку надо считать по Equity.

А для этого надо не один раз в deinit()-е, а на каждом тике (в start()-е) проводить нужные расчеты.

Но работа замедляется, в принципе, не сильно.

Нормальный эксперт должен иметь встроенную функцию контроля просадки по эквити.... В экстренном случаи принимаются экстренные меры... :)

 
kharko писал(а) >>

Нормальный эксперт должен иметь встроенную функцию контроля просадки по эквити.... В экстренном случаи принимаются экстренные меры... :)

Точно! (вприпрыжку побежал набрасывать код контроля просадки...)

Причём, код по разному должен работать в тестере и в реале. В тестере нужно пользоваться... (вот опять наступаем на грабли непродуманной терминологии) глобальными переменными модуля, а в реале - глобальными переменными терминала.

Причина обращения: