Um pouco surpreendido :) Pensei em partilhar e fazer uma pergunta NÃO retórica. - página 14
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
O optimizador não é exactamente um "testador em escala linear", mas tem os seus próprios métodos de optimização que funcionam eficazmente em grande escala e cálculos repetidos.
Estamos agora mesmo ocupados a acelerar os cálculos de massa. Aqui está um link para os resultados passados, e uma nova versão com cálculos mais rápidos está pronta.
Concordo, não exactamente um "testador linearmente escalonado". Fazem optimizações explícitas, o que é uma coisa muito boa. Contudo, não consigo imaginar como optimizar para um caso univariado de uma situação muito frequente:
A optimização vai para dois parâmetros, um parâmetro (intervalo de 100 valores) não toca nas chamadas do indicador, o segundo (intervalo de 5 valores) toca.
Neste caso, calculará os valores do indicador 500 vezes enquanto procura 500 variantes. Neste caso, irá de facto efectuar um grande número de recálculos. Isto porque o intervalo da segunda variável é apenas 5, e não 500.
Este é apenas o exemplo mais simples. Talvez já tenha tido algumas ideias de como contornar esta escalabilidade linear do testador para o optimizador.
P.S. São exemplos como estes que lhe dão vantagem de velocidade nas suas próprias calculadoras por ordens de magnitude, não por percentagem. Mas estas calculadoras não são universais, por isso a comparação é incorrecta desde o início.
Ok - digamos que existe um optimizador sem computação em nuvem, mas multithreaded, e que suporta C++ e MT4 (e todo o seu subsistema) e é 100 vezes mais rápido do que ele, e 6 vezes mais rápido puramente por código MT5, sim... e "resolve" não só com força bruta e AG, mas também com cerca de mais 50 variantes. Por quanto o compraria? Comprá-lo-ia por $1000? Porquê tão caro? Você e mais dez pessoas serão os únicos compradores. :)
No entanto, não consigo imaginar como optimizar para um caso univariado uma situação muito frequente:
Já posso imaginar algo (mas não completamente). Antes de executar o optimizador, deve efectuar uma análise de dependência sobre os parâmetros de entrada a optimizar (no exemplo acima, duas variáveis são completamente independentes). Em seguida, a optimização é feita primeiro através das variáveis independentes desde a gama mais pequena até à maior (nem sempre correcta, pois depende também da intensidade dos recursos dos mesmos indicadores. Por vezes é melhor contar o indicador luminoso 100 vezes, do que 5 vezes o indicador pesado), cachando os resultados.
É evidente que a implementação de tal optimização é muito complexa (especialmente para o caso da nuvem). Mas se implementado, então pelo menos todos os Expert Advisors criados no MQL5 Wizard serão optimizados ordens de magnitude mais rapidamente. Porque o MQL5 Wizard é uma combinação de um grande número de indicadores entre si (ou seja, há um grande número de parâmetros de entrada independentes uns dos outros). Outra coisa é que tal actividade não faz sentido para o comércio lucrativo...
O cache seguido de resultados de amostragem em enormes (milhões e dezenas de milhões) amostras é mais caro do que o cálculo directo.
O cache com a subsequente amostragem de resultados em enormes (milhões e dezenas de milhões) amostras é mais caro do que o cálculo directo.
Tenho a certeza de que é quase irrealista implementar um optimizador universal perfeito para que seja tão "inteligente" como descrevi acima. É claro que há espaço para melhorias, mas não pode ser perfeito em qualquer caso.
Amostras enormes (dezenas de milhões), é claro, exagera consideravelmente. Não há qualquer necessidade de guardar tais coisas.
Penso que todos compreendem perfeitamente o que quero dizer. E muitos fazem-no. Ninguém o criticará sequer por isso, caso contrário seria a ignorância dos programadores sobre os críticos. Porque aqueles que são adequados estão bem cientes da dificuldade de implementar tais coisas.
Explicarei o significado de caching usando o mesmo exemplo:
Se o indicador não for redesenhado, então no final de uma única corrida no testador terá um buffer completo de todos os valores do indicador. Já o tem. E, se a próxima passagem utilizar os mesmos valores indicadores (a segunda variável não mudou), não temos de a ler novamente. Pode tirar valores do buffer já calculado (que já tem, não há necessidade de o guardar em cache, a memória da execução anterior não é completamente livre).
Se o indicador não for redesenhado, então
Tenho a certeza de que é quase irrealista implementar um optimizador universal perfeito para que seja tão "inteligente" como descrevi acima. É claro que há muito espaço para melhorias, mas de qualquer forma não pode ser feito na perfeição.
Amostras enormes (nas dezenas de milhões), claro, exagera isso consideravelmente. Não há qualquer necessidade de esconder algo assim.
Por exemplo, o teste EURUSD dos últimos 11 anos dá mais de 50 milhões de carraças.
Isto significa que um simples indicador de um tampão como MA terá de armazenar 50 milhões de estados (50 milhões * 8 bytes(duplo) = 400 mb tampão), o que é demasiado. Se for utilizado algo mais complexo ou maior em número, de facto a cache não caberá na memória, quanto mais nos agentes multi-core.
Estávamos a trabalhar na ideia de caches indicadores e verificou-se que é muito mais rápido e menos consumidor de recursos calcular o próximo valor indicador (e mesmo com um método económico) do que construir caches.
Sim, precisamente porque é impossível escrever um optimista universal tão rápido, os moinhos numéricos não universais ganharão sempre em termos de velocidade. E não há nada de bom ou de mau nisso.
Eles não ganham nada.
Não têm ambiente de mercado, não têm infra-estruturas, não têm indicadores, não têm análises. E isto é mais importante do que um ciclo único (e nem sequer representado).
Por exemplo, o teste EURUSD ao longo dos últimos 11 anos dá mais de 50 milhões de carraças.
Estamos a falar de um optimista, não de tantos testes únicos. O conceito de optimista é bastante diferente. São obtidos ganhos de velocidade significativos à custa de pequenos erros nos resultados. O optimizador não precisa de modelos baseados em carraças. No máximo, baseiam-se nos preços de abertura. Um optimizador não é um testador, é outra coisa completamente diferente. A sua abordagem é diferente, e bastante lógica também.
Eles não estão a ganhar nada.
Não têm ambiente de mercado, não têm infra-estruturas, não têm indicadores, não têm análises. E isso é mais importante do que um ciclo único (e nem sequer representado).
Ganham em velocidade, porque nada pode ser mais rápido do que o por ciclo sozinho. Por vezes a velocidade é exactamente o que se precisa, e uma calculadora irá bater qualquer testador universal em velocidade (mas não em outros parâmetros). Não só de MetaQuotes.
Não posso provar a minha afirmação pela seguinte razão:
A minha calculadora é simplesmente uma implementação em C++ da minha EA, onde todas as operações são especificamente feitas inteiras (os preços são inteiros), onde os passes desnecessários, etc., são completamente reduzidos a zero. Não há ali nenhuma interface, nada. A única saída é um ficheiro com resultados de optimização. Isto é, posso escrever um EA com optimização algorítmica em C++ e o meu testador não fará qualquer verificação comercial (por exemplo, verificar se há margem suficiente, etc.). Não emulará a história e não contará indicadores. Não há nada de universal em termos de versatilidade do testador MT5. A única tarefa da calculadora é calcular rapidamente, o mais rápido possível. E conta cem vezes mais rápido que o testador MT4, produzindo um erro de <1%. Não compreendo o que estou a tentar mostrar aqui.
É óbvio que para loop sem verificações e com apenas inteiros contará sempre mais rapidamente do que um testador universal.