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
este é o mesmo resultado! os parâmetros de entrada para estes pontos são os mesmos!
Explique, por favor. Não compreendo "os parâmetros de entrada para estes pontos são os mesmos". Tanto quanto sei como funciona o optimizador, cada passe corresponde a um conjunto único de parâmetros de entrada. Ou quer dizer que ao utilizar o algoritmo genético podem existir situações em que um conjunto único de parâmetros de entrada pode ser processado pelo optimizador várias vezes?
...Bem, sim, é exactamente isso que está a dizer. Acontece então que todos os pontos subsequentes "da cache" são apenas uma ficção, distorcendo a percepção visual dos resultados da optimização?
Estranho. Esta é a terceira vez. Há dois pontos no gráfico que estão próximos em valor, mas há apenas um nos resultados.
Dica: Por favor ordenar pelo valor solicitado, e não se esqueça de mostrar a barra de deslocamento vertical da mesa.
Será este problema alguma vez resolvido???
Esta é a terceira vez que falo sobre isto e não há reacção!
A propósito, parece-me que se for seleccionada a modelação de requotes, então esta cache não deve ser utilizada. o que pensam os criadores sobre isso?
e outro bug: quando o meu algoritmo genético foi além de 10496, o gráfico começou a exibir incorrectamente - verticalmente escalou correctamente, foi possível compreender que foram encontrados resultados superiores, mas horizontalmente não foi actualizado. pontos como se fossem adicionados algures à direita, já para além da margem do gráfico.
No terminal, o resultado
Resultado em testador:
Toda a beleza da função SymbolName(i) é perdida
Um pedido aos criadores. Enquanto o trabalho no MT5 está a ferver e ainda estão a ser feitas alterações, seria muito bom expandir o número de passagens de optimização.
Tanto quanto entendi, a solução para tantas tarefas é encontrada para cerca de 10 000 variantes pode ser um pouco mais ou um pouco menos. Foram encontradas algumas horas de pesquisa num único processador e as melhores variantes.
A versatilidade dos testes MQL5+OP+Multicore permite-nos olhar para novos horizontes de tarefas (por exemplo, procura de padrões) que podem ser resolvidos usando ferramentas MT5.
Mas aqui está o problema:
O artigo publicado no seu site tem um exemplo de algoritmo genético https://www.mql5.com/ru/articles/55 onde foi necessária 3^100 força bruta para resolver um problema de busca em 100 barras - bem isso é um pouco mais do que LongInt :) enquanto a solução foi encontrada em 17 000 iterações. O algoritmo genético pode encontrar soluções para muito mais variantes do que a LongInt. E esta limitação é completamente infundada e obsoleta. Bem, excepto que nesta fase final do MT5 será difícil fazê-lo.
Um pedido muito grande aos criadores, se não for muito difícil, por favor faça o número de passes pelo menos 2^LongInt (2 para a potência).
Código:
Diário de bordo:
2010.12.06 18:07:52:52 testInd (EURUSD,H1) Modificado? Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle1 =10
Portanto, todas as chamadas de dados a tratar2 são equivalentes a chamadas a tratar1, apesar do período alterado.
Quando o Expert Advisor está em funcionamento, é possível criar indicadores com as mesmas características e tal optimização para uma pega é razoável, mas tal "colagem" de uma pega a uma variável é muito irritante.
P.S. Descobri a razão. Este bug é uma consequência da optimização de um número de manuseamento.
IndicatorRelease(handle2); //уменьшает счетчик хендлов на единицу и в итоге следующий созданный хэндл(с любой переменной) - опять 10
Código:
Diário de bordo:
2010.12.06 18:07:52 testInd (EURUSD,H1) Modificado? Manípulo2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle1 =10
Assim, todas as chamadas a tratar2 são iguais às chamadas a tratar1, embora o período seja alterado.
Durante o funcionamento de uma EA, não podemos excluir a criação de indicadores com as mesmas características, e tal optimização para uma pega é razoável, mas tal "colagem" de uma pega a uma variável é muito irritante.
P.S. Descobri a razão. É um bug - a consequência da optimização para um número de manuseamento.
O que o leva a pensar que é um insecto?
O que o faz pensar que é um insecto?
Se um utilizador introduzir valores de período para MA a partir da interface, criar alças para indicadores e utilizar valores de buffers de indicadores, depois de ter criado (por exemplo, tenho definições padrão neste formulário) 2 indicadores com as mesmas características (as suas alças são armazenadas na embalagem do objecto), recebe o número da alça do primeiro indicador, devido a esta característica.
O seguinte é uma possível cadeia de acontecimentos.
Situação 1. apaga o primeiro indicador (e o programa executa IndicatorRelease); como consequência, o segundo indicador não funciona automaticamente - erro de cópia de buffer.
Situação 2. Remove o segundo indicador (e o programa faz IndicatorRelease), o contador de comprimento de mão diminui. O primeiro está a ir bem. Cria um terceiro indicador com um período diferente. Recebe a contagem do cabo+1, ou seja, o número do cabo do indicador acabado de apagar. No final, o pior é que o terceiro indicador com um período diferente, criado com sucesso, dá os valores do primeiro indicador, ainda não eliminados, ao tampão.
A função de colagem de números de punho, conduz a situações ambíguas ao eliminar um de dois colados e depois criar novos.
Alguém me responderá por mim?
Já se falou sobre isso aqui.https://www.mql5.com/ru/forum/1997/page6/#comment_31644
Talvez fosse melhor deslocar a questão para lá - uma sugestão.