Erros, bugs, perguntas - página 1998
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 argumento que não compreendi (quando foi apresentado pela MQ) e não o compreendo agora. A inicialização não vai a lado nenhum. Agora é confiada ao programador da aplicação e ele fá-lo de qualquer forma, mas como a prática demonstra, por vezes com erros. Se fosse feito por um núcleo, o desempenho não seria afectado e não haveria erros.
Por exemplo, vejamos um conjunto de tampão indicador: ao inicializar o indicador, o tampão tem um comprimento zero. O que há para inicializar com zeros? Quando se adiciona outro índice, é ele forçado a ser zerado e depois preenchido com algum valor? Para que serve este zeramento ou enchimento com EMPTY_VALUE? E se houver necessidade de atribuir PLOT_EMPTY_VALUE e não 0 ou EMPTY_VALUE ou forçar um, mas precisamos de outro... Não importa como se corta, acaba por perder o seu tempo.
E uma matriz personalizada... A matriz é declarada para alguns dados diferentes de zero e EMPTY_VALUE. Então, por que deveria ser forçosamente inicializado com algo?
Assim, acontece que afecta o desempenho na maioria dos casos.
Mas uma matriz personalizada... A matriz é declarada para alguns dados que não sejam zero e EMPTY_VALUE. Então, qual é o objectivo de inicializá-lo à força com algo?
Ter menos "resultados do testador não coincidem".
Para o tornar menos "os resultados do testador não coincidem".
Quem precisa dele?
Escreva um artigo que diga em cada parágrafo que não se deve encomendar EAs a qualquer pessoa. Tem de escrever os seus EAs correctamente.
Quem precisa dele?
Eu e, tenho quase a certeza, os criadores.
Eu e, tenho quase a certeza, os criadores.
Duvido muito que uma bagatela destas o colocasse numa situação difícil. Ou isso ou há outra razão.
Duvido muito que uma coisa tão trivial o possa atrofiar. Ou a razão é outra.
Mesmo que tenha escrito perfeitamente (sem cometer erros - o que não é o caso), é normal pegar na biblioteca de alguém (por vezes sem código fonte - no Mercado) e utilizá-la, esperando que seja escrita de forma competente. E não há seguro de que depois disso obtenha resultados diferentes no testador. E encontrar a verdadeira causa será MUITO difícil. E a sua fixação é por vezes impossível.
O objectivo é que de corrida em corrida o resultado seja reprodutível - idêntico, mesmo com um erro.
Provavelmente a solução ideal seria forçar a inicialização de todos os programas por defeito + um interruptor de compilação para o desactivar (para aqueles que estão confiantes e querem acelerar um par de por cento).
A inicialização requer realmente muitos recursos. Deitar fora um pedaço de código com inicialização forçada e fiquei quase 2 vezes mais rápido na optimização)
E deparei-me com uma coisa interessante. Como é possível que o drawdown seja de 120% e ao mesmo tempo o resultado esteja no topo e mais?
Quando testei a estratégia, recebi um drawdown de 109% e nenhuma chamada de margem, enquanto o saldo continua a crescer.A inicialização requer realmente muitos recursos. Deitei fora um pedaço de código com inicialização forçada - acelerou na optimização por quase 2 vezes)
Algo que escreveu incorrectamente.
A inicialização completa nem sempre é necessária. Por exemplo, para um indicador que preenche o valor tampão para cada barra no laço (e fá-lo independentemente de o indicador tampão ser inicializado ou não).
Neste caso, será mais económico sem zeragem forçada.
E porquê inventar cenários tão irrealistas, na verdade erros de programador MQL? Obviamente, a inicialização completa é feita apenas uma vez, ou quando é detectada a bombagem de dados. Neste caso, seria feito de forma mais eficiente pelo núcleo.