Пробой утреннего флета - какие пары? - страница 16

Новый комментарий
 
ikatsko писал(а) >>
Несколько переделал индикатор линейной регрессии (автор - Dserg) в следующем направлении: указывается время поиска УТРЕННЕГО флета (с 16:00, но не позже 23:00 до 7:00, но не раньше 1:00). Индикатор находит Nlin и минимальный r0. А сигналы Up[i], Dn[i], Stop[i], Target[i] вырабатываются не сразу по окончании формирования
Здравствуйте! Не могли бы Вы прокомментировать такое поведение индикатора.
Работу его не разбирал. Решил потестировать и увидел не понятное, на мой взгляд, поведение.
Параметры индикатора - по умолчанию.
И если можно, чуть поподробнее, об этом: Индикатор находит Nlin и минимальный r0
 
Dserg писал(а) >>
А вот и советничек подоспел по пробою:


Граально выглядит. Но что самое важное - максимальная серия убыточных сделок всего 2 или 3. Т.е. можно применить мартина по вкусу.
Рубите бабло, не жалко :-)


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



Полностью отчет и set-файл во вложении. Посмотрите, плиз.
Может так задумано автором? Но как то не логично...

Проблема вроде кроется здесь

if (Hour()==h1 ) {
      if (Ns==1 && Nb==1 && n>0) {
         n--;
         Coeff /= Fact;
      }
         
      CloseBuyStopOrder();
      CloseSellStopOrder();
   }  
Файлы:
a2.zip  29 kb
 
renoshnik писал(а) >>
Можно присоедениться к разговору?
Я тут выкладывал советника на пробой сессионных уровней и решил его поднастроить на "ночной флет" - довольно приятная картинка получилась в тестере...

если подробней тогда здесь - http://voloshin-fxcci.blogspot.com/2010/03/blog-post_18.html
сам советник тут - https://www.mql5.com/ru/code/9465


В чем смысл был ....поднастроить под ночной флет
Он если на сессиях завязан
".....Забыл небольшой коментарий к картинке - если заметили - то на графике есть зубцы, это работает вот такой блок программы...."

ессественно в советнике что выложен этого нет :)


 
lasso >>:


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



Полностью отчет и set-файл во вложении. Посмотрите, плиз.
Может так задумано автором? Но как то не логично...

Проблема вроде кроется здесь


Я уже забыл, в чём там конкретно дело, но идея была следующая:
RiskCoeff в зависимости от величины флета выравнивает риск на сделку. Fact отвечает за шаг мартина. Т.е. если выставляем Fact=1 то все прибыльные сделки должны быть одинаковые. За что отвечает конкретно этот участок кода, я к сожалению не помню.
 
Dserg писал(а) >>


Я уже забыл, в чём там конкретно дело, но идея была следующая:
RiskCoeff в зависимости от величины флета выравнивает риск на сделку. Fact отвечает за шаг мартина. Т.е. если выставляем Fact=1 то все прибыльные сделки должны быть одинаковые. За что отвечает конкретно этот участок кода, я к сожалению не помню.

Там получается, если два стоп-ордера не сработали до начала следующего "цикла", они удаляются и шаг ступени мартина (n--) сбрасывается на единицу (что логично), а вот это 

Coeff /= Fact;

не понятно зачем. Ну, да ладно. Разберемся.
// ----
А я думал, что только я такой забывчивый ......
Оказывается не все так у меня плохо. :-))))

 
Dserg писал(а) >>

Я уже забыл, в чём там конкретно дело, но идея была следующая:
RiskCoeff в зависимости от величины флета выравнивает риск на сделку. Fact отвечает за шаг мартина. Т.е. если выставляем Fact=1 то все прибыльные сделки должны быть одинаковые. За что отвечает конкретно этот участок кода, я к сожалению не помню.

Хорошо.
Вы можете ответить на простой вопрос: динамика наращивания размера лота на участке выделенном в красной рамке (там шесть сделок) на Ваш взгляд правильна и логична?
На мой вгляд в первой серии (четыре проигрыша и один выигрыш) - все правильно.
Во второй серии (три проигрыша и выигрыш после этого по минимальной ставке) - думаю нет.
 
lasso >>:
Здравствуйте! Не могли бы Вы прокомментировать такое поведение индикатора.
Работу его не разбирал. Решил потестировать и увидел не понятное, на мой взгляд, поведение.
Параметры индикатора - по умолчанию.
И если можно, чуть поподробнее, об этом: Индикатор находит Nlin и минимальный r0

В исходном индикаторе Dserg-a сигналы формируются сразу же после пробоя канала. Но ширину канала надо было задавать вручную. Мое предложение в том, что задается предполагаемое время (диапазон) "ловли" утреннего флета. В течение этого промежутка времени индикатор подбирает МИНИМАЛЬНУЮ ширину канала перебирая варианты каналов от StartTime до FinishTime и только на финише (когда других вариантов нет) рисуется канал с минимальной шириной (r0), длина которого равна количеству баров между Start и Finish (Nlin). И если к этому моменту канал (полученный) пробит, то формируются выходные сигналы. Сейчас думаю над тем, какой можено предложить критерий оптимизации длины канала. Может у кого идеи есть?

 
Dserg писал(а) >>


Я уже забыл, в чём там конкретно дело, но идея была следующая:
RiskCoeff в зависимости от величины флета выравнивает риск на сделку. Fact отвечает за шаг мартина. Т.е. если выставляем Fact=1 то все прибыльные сделки должны быть одинаковые. За что отвечает конкретно этот участок кода, я к сожалению не помню.


Проблема в том, что в ситуации когда два стоп-ордера не сработали до начала следующего "цикла"(напр., до 2:00 утра), они удаляются и шаг ступени мартина (n--) сбрасывается на единицу (что логично), и Coeff /= Fact; возвращается в исходное до этого события значение, а вот переменная lastB не возвращается.

А если вместо конструкции if (lastB-AccountBalance()>0.0) использовать ф-цию И. Кима if (isLossLastPos("0", -1, nMagic)) то все становится на свои места.
В моем случае результаты после исправления улучшились не на много. Но неизвестно как это повлияет на рез-ты советника при других настройках.

Если Вам в лом, могу поправить и выложить здесь.

 
lasso >>:


Проблема в том, что в ситуации когда два стоп-ордера не сработали до начала следующего "цикла"(напр., до 2:00 утра), они удаляются и шаг ступени мартина (n--) сбрасывается на единицу (что логично), и Coeff /= Fact; возвращается в исходное до этого события значение, а вот переменная lastB не возвращается.

А если вместо конструкции if (lastB-AccountBalance()>0.0) использовать ф-цию И. Кима if (isLossLastPos("0", -1, nMagic)) то все становится на свои места.
В моем случае результаты после исправления улучшились не на много. Но неизвестно как это повлияет на рез-ты советника при других настройках.

Если Вам в лом, могу поправить и выложить здесь.


Отлично!

Именно такой функции мне и не хватало.

Буду знать.

 
lasso >>:

Хорошо.
Вы можете ответить на простой вопрос: динамика наращивания размера лота на участке выделенном в красной рамке (там шесть сделок) на Ваш взгляд правильна и логична?
На мой вгляд в первой серии (четыре проигрыша и один выигрыш) - все правильно.
Во второй серии (три проигрыша и выигрыш после этого по минимальной ставке) - думаю нет.

Максимальное количество проигрышей задаётся в переменной Nmax. Сделайте её побольше, и советник будет увеличивать лот дальше. Вообще если в этой серии Nmax=4 то лот был подсчитан неправильно.

1...91011121314151617181920212223
Новый комментарий