Rompendo o apartamento da manhã - quais pares? - página 16

 
ikatsko писал(а) >>
Rediscuti ligeiramente o indicador de regressão linear (por Dserg) na seguinte direção: o horário de busca do apartamento da manhã é especificado (a partir das 16:00, mas não mais tarde do que 23:00 às 7:00, mas não mais cedo do que 1:00). O indicador encontra Nlin e mínimo r0. E os sinais Up[i], Dn[i], Stop[i], Target[i] não são gerados imediatamente após a formação
Olá, você poderia comentar sobre o comportamento do indicador?
Eu não analisei seu trabalho. Decidi testá-lo e vi algum comportamento estranho.
Os parâmetros indicadores são por padrão.
E se possível, por favor, me fale mais sobre isso: O indicador encontra Nlin e mínimo r0



 
Dserg писал(а) >>
Aqui está uma pequena dica sobre a avaria:


Parece ótimo. Mas, o mais importante, a série máxima de negócios perdidos é de apenas 2 ou 3. Assim, é possível usar a martin a seu gosto.
Picar a massa, não é uma pena :-)


Obrigado. O Expert Advisor é muito interessante. Mas durante o atropelamento e fuga, detectei determinação incorreta do tamanho do próximo lote (na moldura vermelha)



O relatório completo e o set-file estão anexados. Veja o plz.
Talvez assim concebido pelo autor? Mas não é lógico...

O problema parece estar aqui

if (Hour()==h1 ) {
      if (Ns==1 && Nb==1 && n>0) {
         n--;
         Coeff /= Fact;
      }
         
      CloseBuyStopOrder();
      CloseSellStopOrder();
   }   
Arquivos anexados:
a2.zip  29 kb
 
renoshnik писал(а) >>
Posso participar da conversa?
Coloquei aqui um EA para a quebra dos níveis de sessão e decidi afiná-lo para "flat noturno" - é uma bela foto no testador...

se mais detalhes aqui - https://www.mql5.com/ru/code/9465
o Conselheiro Especialista está aqui - http://voloshin-fxcci.blogspot.com/2010/03/blog-post_18.html


Qual foi o objetivo do .... - sintonizá-lo para o apartamento noturno
Se estiver vinculado a sessões.
"..... Esqueceu um pequeno comentário à foto - se você notar - há dentes na tabela, ele funciona neste programa de bloco....".

Obviamente, isto não está no Expert Advisor :)


 
lasso >>:


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



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

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


Eu esqueci exatamente do que se tratava, mas a idéia era a seguinte:
O RiskCoeff equilibra o risco por operação, dependendo do tamanho do apartamento. O fato está a cargo da etapa de martin. Isto é, se definirmos Fato=1, todas as negociações lucrativas devem ser iguais. Infelizmente, não me lembro exatamente pelo que esta parte do código é responsável.
 
Dserg писал(а) >>


Eu esqueci exatamente do que se tratava, mas a idéia era a seguinte:
O RiskCoeff se encarrega do risco por comércio, dependendo do tamanho do apartamento. O fato é responsável pela etapa de martin. Isto é, se definirmos Fato=1, todas as negociações lucrativas devem ser iguais. Infelizmente, não me lembro por que esta seção específica de código é responsável.

Aí acontece que se duas ordens de parada não são acionadas antes do próximo "ciclo" começar, elas são removidas e o passo do martin (n--) é redefinido para um (o que faz sentido), mas isto

Coeff /= Fact;

Eu não sei por que. Bem, não importa. Vamos resolver isso.
// ----
E eu pensei que era o único tão esquecido ......
Acontece que nem tudo isso é ruim para mim. :-))))

 
Dserg писал(а) >>

Eu esqueci exatamente do que se tratava, mas a idéia era a seguinte:
O RiskCoeff é responsável por nivelar o risco por comércio, dependendo do tamanho do apartamento. O fato está a cargo da etapa de martin. Isto é, se definirmos Fato=1, todas as negociações lucrativas devem ser iguais. Infelizmente, não me lembro do que é responsável por este fragmento de código.

Ok.
Você pode responder uma pergunta simples: em sua opinião, a dinâmica de aumentar o tamanho do lote na área destacada na moldura vermelha (há seis ofícios) é correta e lógica?
Em minha opinião, na primeira série (quatro perdas e um ganho) - tudo está correto.
Na segunda série (três derrotas e uma vitória depois disso na aposta mínima), eu acho que não.
 
lasso >>:
Здравствуйте! Не могли бы Вы прокомментировать такое поведение индикатора.
Работу его не разбирал. Решил потестировать и увидел не понятное, на мой взгляд, поведение.
Параметры индикатора - по умолчанию.
И если можно, чуть поподробнее, об этом: Индикатор находит Nlin и минимальный r0



No indicador Dserg-a original, os sinais são gerados imediatamente após uma interrupção no canal. Mas a largura do canal tinha que ser definida manualmente. Minha sugestão é definir o tempo esperado (alcance) para "pegar" o apartamento da manhã. Durante este período de tempo, o indicador seleciona a largura MÍNIMA do canal passando por várias variantes de canal do StartTime ao FinishTime e somente no final (quando não há outras variantes) é traçado um canal com largura mínima (r0) cujo comprimento é igual ao número de barras entre o StartTime e o Finish (Nlin). E se nesse momento o canal (obtido) tiver sido quebrado, os sinais de saída são gerados. Estou pensando agora no critério de otimização do comprimento do canal. Talvez alguém tenha uma idéia?

 
Dserg писал(а) >>


Eu esqueci exatamente do que se tratava, mas a idéia era a seguinte:
O RiskCoeff é responsável por nivelar o risco por comércio, dependendo do tamanho do apartamento. O fato está a cargo da etapa de martin. Isto é, se definirmos Fato=1, todas as negociações lucrativas devem ser iguais. Infelizmente, não me lembro do que é responsável por este fragmento de código.


O problema é que, em uma situação em que duas ordens de parada não foram acionadas antes do próximo "ciclo" (por exemplo antes das 2:00 da manhã), eles são removidos e um passo de um passo de martin (n--) é redefinido para um (o que é lógico), e Coeff /= Fato; retorna a seu valor inicial antes desse evento, mas a variável lastB não é retornada.

E
se ao invés de if (lastB-AccountBalance()>0.0) usar a função I. Kim se (isLossLastPos("0", -1, nMagic)) tudo estiver em seu lugar.
No meu caso, os resultados não melhoraram muito após a correção. Mas eu não sei como isso afetará os resultados da EA em diferentes ambientes.

Se você não se importa, posso consertá-lo e afixá-lo aqui.

 
lasso >>:


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

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

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


Isso é ótimo!

Esse é exatamente o tipo de característica que me tem faltado.

Eu vou saber.

 
lasso >>:

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

O número máximo de perdas é definido na variável Nmax. Aumente-o, e o EA aumentará ainda mais o lote. Em geral, se nesta série Nmax=4, então o lote foi calculado de forma incorreta.

Razão: