uma estratégia comercial baseada na Teoria da Onda de Elliott - página 291
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
E neste caso, as condições da experiência não nos permitem considerar estes resultados como evidência de uma vantagem estatística.
Ok.
"SL<MO" o que é MO?
E outra pergunta, como otimizar o SL, pelo menos em poucas palavras? Designá-lo como um parâmetro externo, ou seja, um SL para todas as negociações?
O único pensamento é que é difícil julgar a partir destes resultados, as condições do experimento não são corretas.
Os novos resultados são ainda menos reveladores. Afinal, não há estatísticas!
Dos 21 meses de testes, 10 já terminaram.
Você não está alegando que seu sistema não está errado. Então, ponha um ponto final 20 e veja o que acontece. Pelo menos as estatísticas aparecerão.
E não pensem que o que estamos escrevendo aqui é uma crítica ao Expert Advisor comercial. Em geral, como uma crítica.
A propósito, a mudança para todos os carrapatos levou à diminuição do MO de 38 para 23. Este não é um resultado ruim.
Também seria interessante comparar os mesmos números, mas com paradas em ambos os casos.
MO é a expectativa matemática de ganho.
SL pode ser otimizado de forma muito simples. Produza-o como parâmetro externo e execute a otimização no testador, definindo os limites e o passo. Naturalmente, no código do Expert Advisor você deve adicionar a condição de fechar uma posição quando o preço cair abaixo do SL para comprar e vice-versa para vender.
O único pensamento é que é difícil julgar a partir destes resultados, não as condições da experiência.
Os novos resultados são ainda menos reveladores. Afinal, não há estatísticas!
Dos 21 meses de testes, 10 estão em excesso.
Yuri, não estou de modo algum nervoso, nem ofendido e está perfeitamente bem. :о)))) O MathCAD não tem um prazo de 10 meses porque tem um código que não permite tais acordos, mas por outras considerações. Em termos do modelo, 10 meses de sobreposição não é um erro. Nada "terrível" aconteceu para o modelo - o preço estava sentado no canal (pendurado na borda). A propósito, por causa de casos como este, comecei a tentar prever a própria trajetória.
Você não está alegando que seu sistema não está errado. Então ponha um ponto final 20 e veja o que acontece. Ao menos as estatísticas aparecerão.
Eu não finjo, embora ainda não tenha encontrado nenhum erro óbvio - durante a vida do canal, o preço passa o nível calculado. Mas com certeza eles aparecerão mais cedo ou mais tarde, não tenho ilusões, o modelo tem alguns pontos fracos.
Provavelmente, eu me desviarei do meu plano e usarei paradas. Ainda confio em seus conselhos, já que agora estou olhando a MT como um Neandertal em uma calculadora. No matcad, é simples - as fórmulas como elas são. :о)
Sinta-se à vontade para perguntar, a seu serviço.
Mas para mim é o contrário. :-))
Entretanto, agora não estou olhando para o matcad, mas para o matlab. E não mais como um Neandertal, mas como um Cro-Magnon.
Mais dois pontos:
- Em princípio, é normal esperar uma correlação entre o tempo de manutenção da posição e o valor de lucro. Em pequenos momentos parece estar lá (a olho nu, posso estar errado). Mas em tempos mais longos (novamente "a olho nu") a situação parece mais aleatória. Mas, aleatoriamente, deve haver pequenas vantagens, assim como pequenas desvantagens. E não há menos. Não há saídas de "ajuste" ocasionais no código?
- Quase toda estratégia tem períodos de "aplicabilidade" e "não aplicabilidade". Se o excesso de máscaras de proteção não for aplicável ao período "não aplicável", a introdução de paradas pode ser um desastre para o relatório. E a não adoção pode ser desastrosa para a conta real.
É preciso contá-lo. Se não for a primeira vez, então a segunda vez. Você pode ver como isso acontece no vídeo - https://www.mql5.com/zh/forum/103424
Então há um recálculo automático? Mas, tanto quanto sei, não há sincronização das citações com o tempo do corretor. Ok, se estamos falando de combinar duas peças longas, então o salto de tempo na junção, digamos uma hora, não será de importância principal. Mas e se a história original for um conjunto de peças e as citações de carga preenchem os buracos? Isso seria uma boa mistura.
Depois de carregar a história eu mesmo, imediatamente a transferi para o terminal autônomo e não a misturei com nada.
Decidi ampliar um pouco a minha resposta. Abaixo você pode ver as estatísticas da vida útil dos canais (eurusd, horas) realizadas da seguinte forma: eu fixo a duração do canal, me movo junto com o tempo, construo um canal de duração fixa para cada barra "atual" e estimo sua vida útil (olhando para o futuro, é claro). Ao mesmo tempo, recolhi todos os tipos de parâmetros adicionais dos canais. Neste caso particular, o canal tem um comprimento de 300 contagens.
É claro que é inferior às imagens da transformação wavelet, mas preste atenção à própria forma da curva (ela persiste por outros períodos e citações), o canal quase imediatamente toma uma posição estável, ou seja, um pico segue primeiro, e depois a duração diminui, mas não vice-versa, embora fosse mais lógico esperar exatamente tal imagem. Você pode ver que alguns canais vivem bastante tempo, cerca de 3,5 de sua extensão (deixe-me lembrá-lo que ao olhar para o futuro, os parâmetros do canal não mudam). Portanto, não sei qual é a trajetória do preço durante este tempo, mas é quase certo que durante a existência do canal, o preço passará pelo nível calculado, é claro, se critérios adicionais funcionarem, incluindo o índice Hurst. Pode acontecer em 20 minutos, pode acontecer em poucos dias, pode acontecer em poucos meses. É claro que esta é uma das características desagradáveis - ou acreditar ou recusar o ofício ou permitir uma perda. Características similares em termos de grau de "desagradabilidade", podem ser encontradas em número suficiente em quaisquer outras estratégias e modelos.
Neste modelo não estou procurando uma área de inversão (outros modelos são para este fim). O código do modelo central no MathCAD leva algumas linhas, e o código que bloqueia negócios de 10 meses leva algumas centenas de linhas. Assim, os primeiros testes deste modelo mostraram 20% de perdas (após o bloqueio), agora é 2% no MathCAD, resta ver o que acontecerá na MT.
A propósito, a própria forma da curva é útil. Se você coletar estatísticas (você pode já tê-las coletado) você será capaz de classificar os extremos (seja com base no senso comum ou recorrendo a sistemas profissionais), e observando sua forma próxima ao ponto de referência atual (retrocedendo um canal) você será capaz de estimar o tempo de existência do canal com um alto grau de confiabilidade.
Em geral, os canais fazem muito sentido... mas isso é apenas uma filosofia.
para Candidato
Mais dois pontos:
- Em princípio, é normal esperar uma correlação entre o tempo de manutenção da posição e o valor de lucro. Parece estar presente em pequenos momentos (de olho, posso estar errado). Mas em tempos mais longos (novamente "a olho nu") a situação parece mais aleatória. Mas, aleatoriamente, deve haver pequenas vantagens, assim como pequenas desvantagens. E não há menos. Não há saídas de "ajuste" ocasionais no código?
- Quase toda estratégia tem períodos de "aplicabilidade" e "não aplicabilidade". Se o período "não aplicável" for ultrapassado, a introdução de paradas pode ser um desastre para o relatório. E a não adoção pode ser desastrosa para a conta real.
Exatamente pela razão de ainda ser cedo (teste filosófico) eu estava balançando como um barco Marquesan quando Yuri me pregou com um SL na parede. E praticamente me convenceu a SL com uma palavra gentil e uma pistola. :о)
A propósito, eu não estava usando o Stop Loss como parâmetro de ordem antes e o implementei através do controle de uma posição aberta, já que as condições estão sempre mudando.
para Yurixx
Yuri, por favor me ajude com o SL. :о)
Como escrevi anteriormente, nunca usei SL, mas usei controle dinâmico de pedidos. Provavelmente não é muito conveniente porque o sistema tem que estar conectado ao servidor o tempo todo, mas na minha opinião faz mais sentido.
Lembro vagamente que tive alguns problemas com o SL (foi há cerca de um ano), ou minha corretora não permitiu colocá-los muito longe ou qualquer outra coisa. De qualquer forma, eu olhei a documentação e "lembrei" que este é o nível de preço em que o pedido é fechado. Ok, eu disse a mim mesmo e digitei os seguintes parâmetros para SL dependendo do tipo de pedido:
Bid-20*Point
Ask+20*Point
Nem uma única operação, agora eu tento entender o porquê, ou melhor, solicitar o código de erro. Eu entrei em mais algumas opções, mas nenhum acordo. Eventualmente eu me fartei e especifiquei o nível de preço SL 20.0, funcionou:
Como naquele desenho animado "Eu não entendo nada". Yuri, explique ao dinossauro como defini-los corretamente, e porque o valor de, digamos, 1,2 é pior que 20,0
1. Você não pode colocar SL em nada, mas controlar dinamicamente o nível de preços você mesmo e "fechar" o comércio no caso certo. É tudo simbolismo, não comércio. É apenas um levantamento de estatísticas. Mas, neste caso, tudo deve ser feito manualmente, não utilizando um testador. Em outras palavras, só precisamos escrever um roteiro que percorra a história implementando a estratégia e coletando os resultados em um arquivo. Não há nada de difícil, porque 95% do roteiro é o texto de seu consultor especializado.
2. Se você usa o testador, então o SL deve ser definido nos pedidos que você faz, como é feito no mundo real. O que você escreveu eu ainda não entendo qual é o problema. A maneira mais fácil de resolver isto é cortar os trechos de código onde você declara, define e usa SL e os coloca aqui. Talvez o problema esteja na normalização (todos os preços nos pedidos devem ser normalizados, ou seja, arredondados para a precisão do ponto). A propósito, se você especificou explicitamente 20,0, então esse é exatamente o valor normalizado. E 20*Point não é. Se você tivesse fixado explicitamente em 1,2, isso também funcionaria (para compra). Tente isto:
Bid-20.0*Point
Ask+20.0*Point
Entretanto, mais uma vez: Bid,Ask também pode ser não-normalizado.
É o que eu vou fazer, como eles chamam, como sempre.
2. Se você usa o testador, então o SL deve ser definido nos pedidos que você faz, como é feito no mundo real. Pelo que você escreveu, não entendo qual é o problema. A maneira mais fácil de resolver isto é cortar os trechos de código onde você declara, define e usa SL e os coloca aqui. Talvez o problema esteja na normalização (todos os preços nos pedidos devem ser normalizados, ou seja, arredondados para a precisão do ponto). A propósito, se você especificou explicitamente 20,0, então esse é exatamente o valor normalizado. E 20*Point não é. Se você definir explicitamente para 1.2, isso também funcionaria (para compra)
O problema é que ele dá o código de erro 130 - paradas erradas. :о)
Como é complicado. Existe alguma função que apenas arredonda o número para 4 casas decimais?
Agora, eu não sei qual será a trajetória do preço durante este tempo, mas é quase certo que durante a existência do canal, o preço passará o nível calculado, contanto, é claro, que critérios adicionais funcionem, incluindo o índice Hearst. Pode acontecer em 20 minutos, pode acontecer em poucos dias, pode acontecer em poucos meses.
Então, o canal não se avariou durante aquele comércio de 10 meses (neste drawdown)? Era um canal poderoso, no entanto :)
Ok, eu disse a mim mesmo e introduzi os seguintes parâmetros para SL dependendo do tipo de pedido:
Bid-20*Point
Ask+20*Point
Nem uma única negociação, agora estou tentando entender o porquê, ou melhor, para solicitar o código de erro.
Veja o registro, se a OrderSend não funcionar, há um registro do motivo.