Обсуждение статьи "Контроль наклона кривой баланса во время работы торгового эксперта" - страница 4

 

Погонял советник на всех тиках. Получил такие результаты:

При отключенном управлении баланса прибыль на прогонах: 

0 0 0 6702,44 первая пара

0 0 0 5735,78 вторая пара

0 0 0 3461.48 третья пара

0 0 0 15901,66  все три пары - Должно было получиться 15899,7. Разница 1,96

 

С включенным управлением лотом прибыль на прогонах: 

35 0 0 = 6550,94

0 36 0 = 6956,95

0 0 184 = 3386.44

35 36 179 = 15991.56 - Должно было получиться 16894,33. Разница 902,77

 

Как видно при отключенном автобалансе тоже есть разница, но она обычно микроскопична. При включении контроля лотом разница весьма заметна 5,3% (за счёт разного количества срабатываний уменьшенного лота). Как интересно тут проводить оптимизацию параметров? Какой выход можно придумать?

Каждый прогон на всех тиках занимает  примерно 20-30 минут.

Собираюсь поставить ещё вот такой эксперимент. Взять какой-нибудь простой советник, прикрутить туда систему контроля лота и посмотреть на предмет разницы по прогонам. 

 

 

Кстати при компиляции файла mqh из статьи получаю вот такие вот сообщения:

possible loss of data due to type conversion BalanceSlopeControl.mqh 117 25
possible loss of data due to type conversion BalanceSlopeControl.mqh 118 21
declaration of 'current_slope' hides member declaration at line 682 BalanceSlopeControl.mqh 909 9
0 error(s), 3 warning(s)  1 4
 

Я их в самом начале подправил. Первые два - указал тип приведения. А третье сообщение подправил с помощью корректировки имени сcurrent_slope в 909 строке и соответствующей корректировкой далее в double TBalanceSlopeControl::CalcTradeLots( double _min_lots, double _max_lots ) 

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

Документация по MQL5: Основы языка / Типы данных / Приведение типов
Документация по MQL5: Основы языка / Типы данных / Приведение типов
  • www.mql5.com
Основы языка / Типы данных / Приведение типов - Документация по MQL5
 
solandr:

Погонял советник на всех тиках. Получил такие результаты:

...

Как видно при отключенном автобалансе тоже есть разница, но она обычно микроскопична.

Добейтесь идентичных результатов во всех режимах при тестировании на любом символе.

Для этого  работайте либо по тикам всех символов, либо по таймеру. и контролируйте появление нового бара на всех инструментах.

Баланс расходиться не должен ни на цент. 

Обработчик события "новый бар"
Обработчик события "новый бар"
  • 2010.10.04
  • Konstantin Gruzdev
  • www.mql5.com
Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
 
solandr:

Кстати при компиляции файла mqh из статьи получаю вот такие вот сообщения:

possible loss of data due to type conversion BalanceSlopeControl.mqh 117 25
possible loss of data due to type conversion BalanceSlopeControl.mqh 118 21
declaration of 'current_slope' hides member declaration at line 682 BalanceSlopeControl.mqh 909 9
0 error(s), 3 warning(s)  1 4
 

Я их в самом начале подправил. Первые два - указал тип приведения. А третье сообщение подправил с помощью корректировки имени сcurrent_slope в 909 строке и соответствующей корректировкой далее в double TBalanceSlopeControl::CalcTradeLots( double _min_lots, double _max_lots ) 

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

Вряд ли здесь. Помню что-то правил, но что - не помню)) Вот мой текущий файл.


Файлы:
 
Dima_S:

Вряд ли здесь. Помню что-то правил, но что - не помню)) Вот мой текущий файл.

Спасибо за новую версию файла!

Сравнение содержимого файла с файлом из статьи показывает несколько отличий в новом файле в строках 37, 115, 116, 907, 966.

Посмотрим насколько эти изменеия могут оказать влияние на советник 

 
solandr:

Посмотрим насколько эти изменеия могут оказать влияние на советник 

Пока что ничего принципиально не поменялось. Такое же расхождение в результатах одновременного прогона по всем парам. Буду копать дальше.
 
solandr:
Пока что ничего принципиально не поменялось. Такое же расхождение в результатах одновременного прогона по всем парам. Буду копать дальше.
То есть, получается так: список сделок абсолютно совпадает в любом режиме тестирования - как по всем парам, так и при тестировании только одной. Не совпадают только моменты переключения контроля баланса?
 
Dima_S:
То есть, получается так: список сделок абсолютно совпадает в любом режиме тестирования - как по всем парам, так и при тестировании только одной. Не совпадают только моменты переключения контроля баланса?

Да.

 

Вот чего я уже сегодня накопал.

Полез в инклюдник и начал ставить в интересных местах принты. И вот какую вещь обнаружил при прогоне более чем по одной паре. Обычно данные более-менее адекватные, но иногда отдельные данные из массива улетают в небеса. Откуда это может произойти? Ниже приведён вариант работы при параметре сделок равном 15: 

                                2012.08.08 15:03:00   this.group_result_array[0]=3.105036941761521e+231
ER 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[1]=497.9999999999999
JG 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[2]=-1447.0
ON 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[3]=-75.0
ND 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[4]=-1173.0
DH 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[5]=4697.0
GS 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[6]=-56.99999999999999
DD 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[7]=187.0
JH 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[8]=-914.0
HQ 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[9]=-982.0
MJ 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[10]=805.0
GL 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[11]=385.0
ID 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[12]=-798.0
DJ 0 Core 1 12:09:30 2012.08.08 15:03:00   this.group_result_array[13]=1561.0
FR 0 Core 1 12:09:30 2012.08.08 15:03:00   X[0]=22183803.0 Y[0]=1561.0
FH 0 Core 1 12:09:30 2012.08.08 15:03:00   X[1]=22186960.0 Y[1]=763.0
GL 0 Core 1 12:09:30 2012.08.08 15:03:00   X[2]=22197303.0 Y[2]=1148.0
RE 0 Core 1 12:09:30 2012.08.08 15:03:00   X[3]=22207443.0 Y[3]=1953.0
OM 0 Core 1 12:09:30 2012.08.08 15:03:00   X[4]=22212063.0 Y[4]=971.0
MG 0 Core 1 12:09:30 2012.08.08 15:03:00   X[5]=22225383.0 Y[5]=57.0
FK 0 Core 1 12:09:30 2012.08.08 15:03:00   X[6]=22248723.0 Y[6]=244.0
QR 0 Core 1 12:09:30 2012.08.08 15:03:00   X[7]=22265943.0 Y[7]=187.0
MJ 0 Core 1 12:09:30 2012.08.08 15:03:00   X[8]=22335543.0 Y[8]=4884.0
JS 0 Core 1 12:09:30 2012.08.08 15:03:00   X[9]=22338363.0 Y[9]=3711.0
JD 0 Core 1 12:09:30 2012.08.08 15:03:00   X[10]=22349163.0 Y[10]=3636.0
OM 0 Core 1 12:09:30 2012.08.08 15:03:00   X[11]=22358283.0 Y[11]=2189.0
FF 0 Core 1 12:09:30 2012.08.08 15:03:00   X[12]=22400283.0 Y[12]=2687.0
GS 0 Core 1 12:09:30 2012.08.08 15:03:00   X[13]=22407303.0 Y[13]=3.105036941761521e+231
NL 0 Core 1 12:09:30 2012.08.08 15:03:00   var_0=3.960436915196813e+236 var_1=86864140528.35715
RD 0 Core 1 12:09:30 2012.08.08 15:03:00   this.current_slope=4.559346228613075e+225

 

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

                                2012.05.31 14:41:59   this.group_result_array[0]=-279.9
PF 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[1]=-275.4
MH 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[2]=-302.5
OQ 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[3]=-281.4999999999999
PE 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[4]=-274.4
QN 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[5]=-323.9999999999999
LL 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[6]=1.61390681602331e+116
QE 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[7]=-249.0
PO 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[8]=-249.0
CQ 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[9]=-250.0
OI 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[10]=-249.0
RO 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[11]=-249.0
ME 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[12]=-249.0
DK 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[13]=-250.0
CQ 0 Core 1 12:48:50 2012.05.31 14:41:59   this.group_result_array[14]=-249.0
IE 0 Core 1 12:48:50 2012.05.31 14:41:59   X[0]=22193876.0 Y[0]=-249.0
NL 0 Core 1 12:48:50 2012.05.31 14:41:59   X[1]=22194448.0 Y[1]=-499.0
JG 0 Core 1 12:48:50 2012.05.31 14:41:59   X[2]=22194812.0 Y[2]=-748.0
PN 0 Core 1 12:48:50 2012.05.31 14:41:59   X[3]=22195279.0 Y[3]=-997.0
CR 0 Core 1 12:48:50 2012.05.31 14:41:59   X[4]=22195447.0 Y[4]=-1246.0
LK 0 Core 1 12:48:50 2012.05.31 14:41:59   X[5]=22195632.0 Y[5]=-1496.0
MP 0 Core 1 12:48:50 2012.05.31 14:41:59   X[6]=22196242.0 Y[6]=-1745.0
OI 0 Core 1 12:48:50 2012.05.31 14:41:59   X[7]=22196301.0 Y[7]=-1994.0
PS 0 Core 1 12:48:50 2012.05.31 14:41:59   X[8]=22269123.0 Y[8]=1.61390681602331e+116
DH 0 Core 1 12:48:50 2012.05.31 14:41:59   X[9]=22276026.0 Y[9]=1.61390681602331e+116
HE 0 Core 1 12:48:50 2012.05.31 14:41:59   X[10]=22276174.0 Y[10]=1.61390681602331e+116
QR 0 Core 1 12:48:50 2012.05.31 14:41:59   X[11]=22287959.0 Y[11]=1.61390681602331e+116
NO 0 Core 1 12:48:50 2012.05.31 14:41:59   X[12]=22289679.0 Y[12]=1.61390681602331e+116
DD 0 Core 1 12:48:50 2012.05.31 14:41:59   X[13]=22307227.0 Y[13]=1.61390681602331e+116
EP 0 Core 1 12:48:50 2012.05.31 14:41:59   X[14]=22307921.0 Y[14]=1.61390681602331e+116
HM 0 Core 1 12:48:50 2012.05.31 14:41:59   var_0=5.571865878831281e+121 var_1=33339632014.93333
HE 0 Core 1 12:48:50 2012.05.31 14:41:59   this.current_slope=1.671243964641108e+111 

 
solandr:

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

Да, похоже на то. Посмотрю на выходных. Тоже интересно)
Причина обращения: