O sistema de comércio mecânico perfeito. - página 4
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
Até agora, tudo parece muito mais simples para mim. Você deve começar com um sistema simples e ingênuo, com um mínimo de parâmetros de configuração, e adicionar a ele um bloco de mudança de parâmetros adaptável em tempo real...
Aí está, resta muito pouco a fazer :) Precisamos decidir que dados usar para calcular os parâmetros adaptativos. Eu nem sei o que sugerir :(
Alguém tem alguma idéia a esse respeito?
Posso começar propondo o seguinte modelo TC:
Pegamos o Expert Advisor simples e escrevemos a ele um bloco "testador" (cuja tarefa será - uma vez por dia, por exemplo, à 01:00 GMT para ajustar o TS sob o histórico mensal).
xeon, o testador pode ser feito para trabalhar o tempo todo. Naturalmente, teria que ser escrito em C altamente otimizado, não em mql4. Infelizmente, há uma armadilha muito séria em tudo isso. Nomeadamente, é o período de estimativa e otimização do sistema. Isto é, por quanto tempo avaliar seu desempenho ? Suponha que tenhamos duas estratégias competindo pelo direito de comercialização real. A atual de sucesso e a pior. Em uma hora, por exemplo, a estratégia atual perdeu dinheiro, enquanto que a estratégia de apoio, ao contrário, foi bem sucedida. A questão é mudar as estratégias ou não mudar? Afinal, isto pode ser o começo de uma nova tendência (não confundir com tendência/flit !), ou acidental. Ou seja, acontece que tal testador teria pelo menos um (e importante!!!) parâmetro configurável - o período de avaliação e otimização. Não fique com a idéia de que estou dizendo que tal abordagem é impossível. Só estou dizendo que há dificuldades e lugares obscuros em tudo isso.
Vamos tentar uma abordagem simples afinal de contas.
A tarefa: é possível escrever uma função que executa o histórico mensal uma vez por dia e define o número ideal para o parâmetro de stop loss?
E O MAIOR: Posso usar esta função para verificar o testador? O testador funcionará de alguma forma? Acontece que todos os dias, no modo de teste, deve mudar o parâmetro de parada para um novo dia? É possível? Se esta tarefa for resolvida, o resto é gelo, como já foi dito.
xeon, um testador pode ser feito para trabalhar o tempo todo. Claro que teria que ser escrito em C altamente otimizado, não em mql4. Infelizmente, há uma armadilha muito séria em tudo isso. Nomeadamente, é o período de estimativa e otimização do sistema. Isto é, por quanto tempo avaliar seu desempenho ? Suponha que tenhamos duas estratégias competindo pelo direito de comercialização real. A atual de sucesso e a pior. Em uma hora, por exemplo, a estratégia atual perdeu dinheiro, enquanto que a estratégia de apoio, ao contrário, foi bem sucedida. A questão é mudar as estratégias ou não mudar? Afinal, isto pode ser o começo de uma nova tendência (não confundir com tendência/flit !), ou acidental. Ou seja, acontece que tal testador teria pelo menos um (e importante!!!) parâmetro configurável - o período de avaliação e otimização. Não fique com a idéia de que estou dizendo que tal abordagem é impossível. Só estou dizendo que há dificuldades e lugares obscuros em tudo isso.
Vamos tentar uma abordagem simples afinal de contas.
O problema: é possível escrever uma função que funciona uma vez por dia uma vez por mês e estabelece o número ideal para o parâmetro de stop loss?
E O MAIOR: Posso usar esta função para verificar o testador? O testador funcionará de alguma forma? Acontece que todos os dias, no modo de teste, deve mudar o parâmetro de parada para um novo dia? É possível? Se você resolver este problema, o resto é gelo, como já foi dito.
Tanto quanto sei, é possível escrever tal função em mql, mas esta tarefa não é fácil para mim, porque sou um "programador amador" e preciso de tempo para fazê-la.
Os indicadores auto-ajustáveis são um beco sem saída. Vou tentar justificar minha opinião.
Desenvolvi vários desses indicadores, mas eles pareciam ser sensíveis à volatilidade das cotações provenientes de diferentes corretoras. Ou seja, estes indicadores funcionam bem nos dados de uma corretora e não funcionam de forma alguma nos dados de outra empresa. O pior de tudo é que eles trabalham com dados TC. Por exemplo, nos indicadores padrão no mesmo intervalo de cotações, há divergências em uma corretora e não em outra.
Minha pesquisa mostrou que a volatilidade é o principal fator a ser considerado em um indicador de autoajuste. Entretanto, eventualmente o indicador torna-se dependente da forma de filtragem das cotações em diferentes corretoras e das mudanças deste método (que não é notificado pelas corretoras).
Aqui também me deparei com o fato de que não posso "endurecer" (como Renat sempre diz) o auto-ajuste, porque é constante (linear), e não discreto.
Creio que a única maneira de evitar o problema da volatilidade é ignorar os valores absolutos dos indicadores e das citações. Isto é, para tomar uma decisão na MTS devemos usar a correlação de valores de uma forma ou de outra, e isto é, de fato, o reconhecimento de padrões.
isso!
Os indicadores auto-ajustáveis são um beco sem saída. Vou tentar justificar minha opinião.
Desenvolvi vários desses indicadores, mas eles pareciam ser sensíveis à volatilidade das cotações provenientes de diferentes empresas de corretagem. Ou seja, estes indicadores funcionam bem nos dados de uma corretora e não funcionam de forma alguma nos dados de outra empresa. O pior de tudo é que eles trabalham com dados TC. Por exemplo, nos indicadores padrão no mesmo intervalo de cotações, há divergências em uma corretora e não em outra.
Minha pesquisa mostrou que a volatilidade é o principal fator a ser considerado em um indicador de autoajuste. Entretanto, eventualmente o indicador torna-se dependente da forma de filtragem das cotações em diferentes corretoras e das mudanças deste método (que não é notificado pelas corretoras).
Aqui também me deparei com o fato de que não posso "endurecer" (como Renat sempre diz) o autoajuste, porque é constante (linear), e não discreto.
Creio que a única maneira de evitar o problema da volatilidade é ignorar os valores absolutos dos indicadores e das citações. Ou seja, para tomar uma decisão na MTS devemos usar a correlação de valores de uma forma ou de outra, e isto é essencialmente o reconhecimento de padrões.
Para qualquer sistema, não é o valor do preço que importa, mas a velocidade da mudança de preço (às vezes apenas o sinal).
s vezes é utilizada a aceleração do preço (estimando a força que atua sobre o preço, como um indicador principal).
TODOS os indicadores utilizados com a MTS são, de fato, projetados para estimar a velocidade.
Indicadores diferentes são simplesmente OPÇÕES diferentes para estimar a velocidade.
1. TODOS os osciladores estimam velocidade, às vezes aceleração (como MACD).
2. TODAS as médias móveis NUNCA são utilizadas por conta própria,
somente em comparação com outras médias móveis (preço é um muving com comprimento = 1).
Esta comparação das médias móveis (na verdade comparando sua diferença com zero) é um oscilador.
3. Não é o preço que precisa ser considerado, mas sim o logaritmo do preço.
Em logaritmos tudo se torna mais simples e mais correto.
Para pequenas mudanças no preço, não haverá diferença entre trabalhar com o preço e o logaritmo,
Com grandes mudanças no preço, a diferença será significativa.
Posso lhe dar uma pequena dica? :)
Para qualquer sistema, não são os valores de preço que são importantes, mas a velocidade da mudança de preço (às vezes apenas o sinal).
s vezes é utilizada a aceleração do preço (estimando a força que atua sobre o preço, como um indicador principal).
TODOS os indicadores utilizados com a MTS são, de fato, projetados para estimar a velocidade.
Indicadores diferentes são simplesmente OPÇÕES diferentes para estimar a velocidade.
1. TODOS os osciladores estimam velocidade, às vezes aceleração (como MACD).
2. TODAS as médias móveis NUNCA são utilizadas por conta própria,
somente em comparação com outras médias móveis (preço é um muving com comprimento = 1).
Esta comparação das médias móveis (na verdade comparando sua diferença com zero) é um oscilador.
3. Não é o preço que precisa ser considerado, mas sim o logaritmo do preço.
Em logaritmos tudo se torna mais simples e mais correto.
Para pequenas mudanças no preço, não haverá diferença entre trabalhar com o preço e o logaritmo,
a grandes mudanças de preço, a diferença será significativa.
Ou talvez você também participe da redação do código? :-), com sua experiência em programação iria muito mais rápido!