![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Nas séries temporais matemáticas dividem-se em três grupos (mais são possíveis, mas três são suficientes para descobrir como se comportará um modelo matemático):
1. A BP é ergódica, e consequentemente estacionária. Neste caso, as suas características estatísticas são tão estáveis que existe uma única solução. Isto é, faz sentido construir um modelo matemático e funcionará em qualquer secção da BP - supergrial.
2. O VR é não-ergódico mas estacionário. Este caso é mais complicado, pois as características estatísticas são estáveis apenas por expectativa matemática e dispersão. Aqui já existem muitas soluções. Portanto, vários modelos matemáticos podem ser construídos e com alguma probabilidade de serem rentáveis em certas partes - não super, mas graal, porque podemos comercializar dentro do canal em ricochete a partir das fronteiras do SPE - canal. A BP irá ocasionalmente saltar fora dos limites, mas estes momentos podem ser ultrapassados. Também teremos de esperar e apanhar quando a BP dançar em torno do valor zero, não se aproximando das fronteiras. Para verificar a estacionaridade é necessário e suficiente colocar Bandas de Bollinger na BP e ver que não muda - é uma tendência lateral com canais bastante estáveis.
3. A BP é não estacionária e, portanto, não alérgica. As características estatísticas são instáveis. A situação é mais complicada porque qualquer modelo matemático só é adequado na secção para a qual é calculado - o ajuste. Fora da parcela, será uma confusão. Simplificando, pode acontecer que qualquer modelo matemático ajustado à trama histórica venha a dar uma perda no futuro. É melhor nem sequer sonhar com grails.
Os BP financeiros pertencem à terceira categoria: não estacionários, e portanto não alérgicos. Mas não é tão mau como parece à primeira vista. O facto é que as primeiras diferenças de tais GRs são estacionárias na expectativa e parcialmente, mas estacionárias na variação. Por exemplo, quando a RV está numa tendência, seja lateral ou vertical, as primeiras diferenças são estacionárias durante algum tempo. O momento de transição de um estado estacionário para outro é desconhecido, bem como as características estatísticas do futuro estado estacionário. Podemos restringir-nos a três modelos matemáticos: tendência ascendente de algum segmento, tendência lateral e tendência descendente. Se o TS classificar adequadamente, mesmo que com algum atraso, as transições de um modelo para outro, podemos ganhar dinheiro. Contudo, não há garantia, porque neste caso pode acontecer que nenhum dos três modelos seja rentável se as dispersões mudarem essencialmente e as fronteiras do canal forem determinadas incorrectamente. Um terá de incorrer em perdas e construir três modelos matemáticos seguintes nas secções de história anterior. E por aí adiante e assim por diante. Densa ou vazia.
A julgar pelo facto de ser possível construir um TS adequado que será rentável no futuro em alguns períodos da história. Podemos assumir um ou o outro. O mercado é ergódico não ergódico, algum período de tempo (que podemos tentar explorar). Portanto, a tarefa inicial é a seguinte.
1 Cluster o mercado. Se existe uma tendência, então que tipo de tendência, se existe um flat, então que tipo de transição (é uma rede neural separada com um pincel para o artigo sobre Kohonen)
2 Determinar o cluster em que estamos no momento
3 Escolher ou seleccionar na base de dados a estratégia responsável pelo cluster actual.
Estamos a passar por um momento difícil. Seleccionar os argumentos mínimos que descrevem o mercado (li o artigo sobre análise discriminatória). Escolher a janela temporal do momento actual. Bem, para recolher estatísticas sobre o período de tempo em que se encontra o mercado (quer tenhamos tempo para remover fichas da mesa ou não).
Acrescentei uma aula para criar um optimizador de AG. Agradecimentos especiais a Roman Rich e joo pelos seus artigos.
No optimizador da classe GA do reboque e um exemplo da sua utilização no guião. Se não tiver dificuldade em executá-lo. Aqui são enviadas perguntas sobre o uso e bugs.
Acrescentei uma aula para criar um optimizador de AG. Agradecimentos especiais a Roman Rich e joo pelos seus artigos.
No optimizador da classe GA do reboque e um exemplo da sua utilização no guião. Se não tiver dificuldade em executá-lo. Perguntas sobre a utilização de bugs e plz aqui .
Não muito preguiçoso, fugiu.
2011.11.18 17:30:10 PrimerGA (EURUSD,D1) X1 = 3,068966720346887 X2 = 3,315651165492819 Solução = -4,31815752349534
2011.11.18 17:30:07 PrimerGA (EURUSD,D1) X1 = 3,029136351314492 X2 = 3,309540883455843 Solução = -4,263691893969934
2011.11.18 17:30:00 PrimerGA (EURUSD,D1) X1 = 2,449305079854762 X2 = 2,817163285313374 Solução = -4,174465090531069
2011.11.18 17:29:52 PrimerGA (EURUSD,D1) X1 = 3,063254884005564 X2 = 3,31307567474783155 Solução = -4,314453236316976
2011.11.18 17:29:40 PrimerGA (EURUSD,D1) X1 = 3,07864936362527705 X2 = 2,169112355456941 Solução = -4,25838612042264
Porque é que a solução tem uma dispersão tão grande?
Não se deu ao trabalho de o fazer passar.
Não se obtém a melhor solução, mas bastante aceitável. A função em si parece um ouriço, obrigado joo. Se se quiser aumentar a precisão terá de sacrificar quantidade de cálculos, na minha opinião esta é uma relação menos óptima. Estava interessado não no problema de alta complexidade, mas sim no aspecto prático. Usabilidade, bugs .....
Esta função é florida (macia e fofa) em comparação com o que está prestes a fazer.
Lado prático: não descobri como aumentar a precisão sem interferir directamente com o código.
Esta função é florida (macia e fofa) em comparação com o que está prestes a fazer.
Lado prático: não descobriram como aumentar a precisão sem interferir directamente com o código.