Resultados de testes de peritos multimoedas - página 5
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
De que realidade está a falar? Testes em tempo real? Se assim for, então concordo, claro. Se pendurar dois EAs nos seus símbolos, tudo estará correcto. Mas estou a testar o modo multi-divisas. E um resultado idêntico é mostrado apenas usando OnTimer() (10 segundos).
Estou a falar de uma corrida real em modo de moedas múltiplas (negociação com símbolos N em EAs (em cada EA) definidos para cada um dos símbolos) - que dá uma estimativa real, e no caso do testador está principalmente a comparar os modos de teste, não a correcção de cada um dos métodos de processamento de carrapatos de moedas múltiplas. De que serve comparar diferentes modos se todos eles se baseiam no ambiente artificial do testador? A identidade dos resultados das corridas não é motivo para afirmar que dá os resultados mais correctos em termos de negociação, mas sim o óptimo em termos do funcionamento interno do testador.
Vamos começar com a redacção correcta. No exemplo original teria querido "negociar em Eurodólares". De facto, os eventos personalizados vinham de dois símbolos e no manipulador de eventos TradeSignalCounter()+TradePerformer() eram chamados quando os eventos de qualquer um destes dois símbolos eram recebidos. Podemos assumir que a fila do evento esteve sempre cheia.
Agora retirou uma das fontes de sinal mas introduziu a verificação"if(sparam == Symbol_01)" no manipulador do evento por alguma razão. Mas a questão seguinte é diferente. A julgar pelo código, o esquema de Lizar é utilizado no modo "Todos os ticks" e as funções TradeSignalCounter()+TradePerformer() são chamadas a cada tick da fonte do sinal (EURUSD). O interesse já deu a entender um possível transbordo da fila de eventos. Mas quero saber que instrumento é utilizado como parâmetro Symbol_01 destas duas funções, e se tentou alterar a periodicidade dos eventos no esquema de Lizar.
Sim, era isso que eu queria fazer. Afinal de contas, cada acção que tomamos é desencadeada pelo nosso desejo. Neste caso, consegui exactamente o que queria. Ou seja, negociámos apenas no EURUSD, porque a função TradePerformer() verifica se é permitido negociar para cada símbolo da gama de símbolos. Esta opção está localizada em variáveis externas e, nessa altura, a negociação usando o símboloGBPUSD era proibida. Os eventos do utilizador vieram de dois símbolos, mas no manipulador de eventos, mais uma vez, a função TradePerformer() só permitia o comércio com o símbolo EURUSD. A funçãoTradePerformer() também contém uma função que determina se uma nova barra ocorreu num determinado símbolo, neste caso o EURUSD. A sua suposição de que a fila de eventos esteve sempre cheia está correcta, mas neste caso tudo foi processado separadamente e um tick atrasado não é significativo quando se testa em barras diárias.
A remoção de uma fonte de sinal, aquela que não deveria estar envolvida nos testes, apenas confirmou que tudo tinha sido feito correctamente antes. A verificação"if(sparam == Symbol_01)" permaneceu desde quando verifiquei os resultados sem apagar a fonte do sinal em que os testes não deveriam ter lugar, mas a partir da qual deveria ter lugar. Este cheque acabou por se revelar até supérfluo. Os resultados não se alteraram. O símbolo EURUSD é utilizado como parâmetro Symbol_01. Tentei alterar a frequência dos eventos, mas não mudou nada. Mais precisamente, posso dizer que o modo "all ticks" é o mais preciso.
Estou a falar de uma corrida real em modo de moedas múltiplas (negociação com símbolos N em EAs (em cada EA) definidos para cada um dos símbolos) - que dá uma estimativa real, e no caso do testador está principalmente a comparar os modos de teste, não a correcção de cada um dos métodos de processamento de carrapatos de moedas múltiplas. De que serve comparar diferentes modos se todos eles se baseiam no ambiente artificial do testador? Os resultados idênticos das corridas não nos permitem afirmar que dá os resultados mais correctos do ponto de vista do comércio, é o óptimo do ponto de vista dos mecanismos internos do testador.
Agora compreendo. Mas a discussão foi originalmente centrada nos testes no testador. Antes de começar a negociar, é necessário testar o sistema. Quanto mais preciso for o teste, tanto mais confiante se sentirá no comércio real. Os resultados dos testes aqui apresentados mostram que os testes podem ser feitos de forma correcta e errada. Agora cada um tem uma escolha e pode decidir por si próprio o que é certo ou errado. Um comerciante disse com razão (se não estou enganado, é Van Tharp): "Nós negociamos com as nossas percepções". Posso acrescentar a isso. Não comercializamos apenas as nossas ideias. Vivemos mesmo de acordo com as nossas percepções. ))
Se anexarmos um consultor especializado separadamente a cada símbolo no comércio ou teste real, este será o mais exacto. Claro, concordo com isso. Mas não há necessidade de sincronização em barras para isso. A exactidão será acompanhada pela duração. É possível estimar longos períodos históricos no testador. E eu pessoalmente prefiro ver os resultados correctos dos testes.
Também quero sublinhar mais um ponto: nunca excluo a possibilidade de estar errado algures e controlo sempre tudo. Mas mesmo depois dos testes mais difíceis, quando à primeira vista tudo parece correcto, ainda não excluo a possibilidade de que possa haver um erro algures. Neste ponto, se alguém discordar da avaliação dos resultados dos métodos de teste apresentados, terá de fornecer os seus próprios resultados de teste em comparação. Afinal, o objectivo deste tópico é descobrir como fazer a coisa certa ou, para ser mais preciso, como testar correctamente os Expert Advisors com várias moedas, e não quem está certo ou errado apenas por palavras. Os factos, apenas os factos e nada mais que os factos! )))
De que serve comparar diferentes modos se todos eles se baseiam num ambiente de teste artificial?
O objectivo é tomar uma decisão correcta com base nos resultados. E certamente não vejo qualquer utilidade em analisar dados distorcidos. Afinal de contas, colhe-se o que se semeia).
A remoção de uma fonte de sinal, a que não deveria estar envolvida no teste, apenas confirmou que tudo tinha sido feito correctamente antes.
"...foi feito mesmo antes" é da categoria de complacência. Estava errado em primeiro lugar. Não parece atribuir importância a um fenómeno como "sobrelotação de filas de eventos". Particularmente quando se trata de transmissão pós-ítica de eventos. Veja os materiais de referência e o fórum sobre o assunto. A palavra-chave é "fila".
... Só negociei no EURUSD porque a função TradePerformer() verifica se é permitido negociar para cada símbolo no conjunto de símbolos. Esta opção está localizada em variáveis externas, e nessa altura a negociação com o símboloGBPUSD era proibida. Os eventos do utilizador vieram de dois símbolos, mas no manipulador de eventos, mais uma vez, a função TradePerformer() só permitia o comércio com o símbolo EURUSD. A função TradePerformer() também contém uma função que determina se uma nova barra ocorreu num determinado símbolo, neste caso o EURUSD. A sua suposição de que a fila de eventos esteve sempre cheia está correcta, mas neste caso tudo foi processado separadamente e um tick atrasado não é significativo quando se testa em barras diárias.
Desde TradeSignalCounter()+TradePerformer() processaram eventos de apenas uma fonte de sinal, o estado de fila e o seu possível transbordo não se alterou em absoluto. Por outras palavras, a "proibição de processar eventos por símbolo GBRUSD" não removeu de todo os eventos apropriados da fila. Pela terceira vez, estou a apontar o problema: "Um possível transbordamento na fila de eventos já foi sugerido" :) Se acredita que se trata apenas de "um carrapato atrasado", qual é a base para tais conclusões?
"...Neste caso, tudo foi tratado separadamente". O problema é que na versão original, o manipulador de eventos chamava funções quando os eventos eram recebidos de ambas as fontes de sinal, e depois essas funções já filtravam o sinal da fonte "desnecessária". Mas as funções foram chamadas a cada (!) tempo.
Um atraso de um tick não é significativo quando testado em barras diárias.
Não importa em que período o manipulador do evento é testado. Se o esquema de Lizar gerar sinais tique por tique, então eles também estão a marcar a fila do evento tique por tique, não uma vez por dia.
"Tentei mudar a frequência dos eventos, mas não fez qualquer diferença. Mais precisamente, posso dizer que o modo "all ticks" é o mais preciso". Poderia, por favor, fornecer capturas de ecrã comparativas nos modos sem stick da Lizar?
Se colocar uma EA em cada símbolo separadamente no comércio ou teste real, essa seria a opção mais exacta. Claro, concordo com isso. Mas não há necessidade de sincronizar as barras. A exactidão será acompanhada pela duração. É possível estimar longos períodos históricos no testador. E eu pessoalmente prefiro ver os resultados correctos dos testes.
O objectivo é tomar uma decisão correcta com base nos resultados. Mas definitivamente não vejo qual o interesse em analisar dados corrompidos. Afinal de contas, colhe-se o que se semeia).
O que estou a tentar salientar é que a categoria de "correcção" foi agora substituída pela identidade dos ensaios, mas isso não significa que tais dados estejam menos distorcidos. Em particular, escolheu agora um intervalo de 10 segundos, que é sem dúvida mais distorcedor do que, por exemplo, um intervalo de 5 segundos ou 1 segundo. Ou seja, está a explorar alguma característica nas condições de funcionamento do testador que lhe dá o método preferido com o temporizador de 10 segundos. De facto, está a tentar "apanhar" o momento da chegada de carraças de barras novas em todos os instrumentos com eventos temporizados, e é bastante óbvio que a melhor maneira de o fazer é com o evento OnTick.
Não perca o seu tempo. Nunca conseguirá uma correspondência perfeita em carraças. O tempo de fecho de um bar é diferente para diferentes instrumentos.
Para um instrumento, a hora actual é a do fecho do bar, para outro ainda não foi formado, e para o terceiro foi formado há vários carrapatos.
Veja-se a história das carraças, o volume das carraças difere muitas vezes de instrumento para instrumento.
Yedelkin 2011.08.25 08:16 #
"...tudo já foi feito antes" é da categoria de complacência.
---
Bom dia! ))
Para além desta frase separada, também escrevi: ".Nunca excluo que esteja errado algures e verifico sempre tudo. Mas mesmo depois das verificações mais difíceis, quando à primeira vista tudo parece certo, ainda não posso excluir a possibilidade de que possa haver um erro em algum lugar". Devo acrescentar que não sou o tipo de pessoa que pensa que tem sempre razão em tudo. )))
---
Yedelkin:
Estava originalmente errado. Aparentemente, não se atribui importância a um fenómeno como "sobrelotação de filas de eventos". Particularmente quando se trata de transmissão pós-ítica de eventos. Veja os materiais de referência e o fórum sobre o assunto. A palavra-chave é "fila".
---
Deu uma vista de olhos ao tema do Temporizador. Os pontos-chave que salientei são:
1. Enquanto um evento está a ser processado, os outros podem não ser processados.
2. Se a pilha de eventos transbordar, os eventos antigos são removidos da fila sem serem processados.
Vamos tomar em ordem. Há uma enumeração de eventos:
Ao rubricar, especificar de que símbolo aceitaremos o evento e qual o evento que aceitaremos:
Ou seja, aceitaremos o evento CHARTEVENT_TICK apenas a partir do símbolo EURUSD. Não existem outros símbolos.
O teste já começou. Quando qualquer evento ocorre, o programa entra na função OnChartEvent(), declara conjuntos de variáveis para sinais de negociação e verificações para o evento. Se este for um evento personalizado, o programa determina o sinal em TradeSignalCounter(), então verifica se ocorreu uma nova barra na função TradePerformer() e depois decide sobre outras condições, dependendo disto. A função termina o seu trabalho e só o inicia quando um evento ocorre no gráfico EURUSD. Por outras palavras, um tique neste caso.
Yedelkin:
Pelo facto de TradeSignalCounter()+TradePerformer() ter tratado de eventos a partir de uma única fonte de sinal, o estado da fila de eventos e o seu possível transbordo não se alterou de forma alguma. Por outras palavras, a "proibição de processar eventos por símbolo GBRUSD" não removeu de todo os eventos apropriados da fila. Pela terceira vez, estou a apontar o problema: "Um possível transbordamento na fila de eventos já foi sugerido" :) Se acredita que se trata apenas de "um carrapato atrasado", qual é a base para tais conclusões?
---
A execução das funções listadas é muito rápida. Não há excesso de filas de eventos e não faltam eventos significativos. E se a fila mesmo transbordar e os eventos forem perdidos, o que é que vamos perder? Um carrapato, dois carrapatos, três? E então? É insignificante nos bares diurnos.
---
Yedelkin:
O problema é que na versão original, o manipulador de eventos chamava funções quando os eventos vinham de ambas as fontes de sinal, e depois essas funções já filtravam o sinal da fonte "desnecessária". Mas as funções foram chamadas a cada (!) tempo.
---
Porque é que se agarra a esta segunda fonte?)) Já não existe uma segunda fonte. Existe um - EURUSD, mas o Expert Advisor negoceia a partir do gráfico GBPUSD para EURUSD. E os resultados são identicamente errados. Uma cópia. Ou seja, são os mesmos como se a segunda fonte estivesse presente. )))
-----------
É melhor ser você a fazer o teste, mostrar os resultados e escrever (brevemente) o que fez para obter os resultados correctos do teste, se conseguir fazê-lo, claro. O perito mais simples fará para este teste. Entrada por qualquer condição, Stop Loss, Take Profit. Que sejam as barras diárias dos últimos 10 anos. E verá com os seus próprios olhos. Alguns períodos serão coincidentes, e outros não. Abrir a tabela de resultados para ver onde se encontra o desfasamento.
Como é que não precisa de fazer a sincronização de bares online!
Porque escreveu antes disso:
marketeer:
Estou a falar de uma corrida real em modo de múltiplas moedas (negociação em símbolos N em EAs (em cada EA) definidos para cada um dos símbolos) - isto dá uma estimativa real...
A partir disto, entendo que por corrida real se entende um teste online, quando vários EAs estão a correr e cada um está a pairar directamente sobre o seu próprio símbolo. Se era a isso que se referia, então uma pergunta. Porque é que precisamos de sincronização de barras neste caso, se cada Expert Advisor está localizado no seu próprio símbolo? Talvez, a sincronização de barras neste caso seja necessária se o sistema de comércio for organizado de tal forma que seja tomada uma decisão sobre vários símbolos ao mesmo tempo, pelo que as barras sobre estes vários símbolos devem ser formadas. Pretendo trocar independentemente em vários símbolos enquanto estiver sobre um símbolo (sobre qualquer símbolo).
Marketeer:
Todas estas experiências no testador são necessárias para estimar o comércio online, e a questão deste tópico não é sobre o testador (que emula online), mas sim online, e acima de tudo é necessária a sincronização de barras online (para Consultores Peritos apropriados).
Para mim, as experiências do testador são necessárias para avaliar os resultados do comércio sobre a história. E a minha escolha do comércio em linha depende desta avaliação. Portanto, a questão deste tópico é a questão do testador, não a questão online, razão pela qual precisamos de sincronização de barras também no testador (para Consultores Especialistas correspondentes). Algumas imagens-espelho))))
Marketeer:
O que estou a tentar salientar é que a categoria "correcção" foi agora substituída pela identidade dos ensaios, mas isso não significa que tais dados sejam menos enviesados. Em particular, escolheu agora um intervalo de 10 segundos, que é sem dúvida mais distorcedor do que, por exemplo, um intervalo de 5 segundos ou 1 segundo. Ou seja, está a explorar alguma característica nas condições de funcionamento do testador que lhe dá o método preferido com o temporizador de 10 segundos.
Sim, quanto menor for o intervalo, mais exacto será o resultado. Mas, na verdade, é necessário, pelo menos para mim, para o último teste. E para a preliminar, eu ainda concordaria com Vladimir(MetaDriver) que o intervalo de um minuto é suficiente.
Marketeer:
Na verdade, com eventos temporizados tenta-se "apanhar" a chegada de carraças de novas barras em todos os símbolos, e é óbvio que a melhor maneira de o fazer é o evento OnTick.
E aqui pode ver que não leu cuidadosamente o primeiro post do fio. Não com eventos temporizados, mas com OnChartEvent(). Ou será um erro de impressão?
A partir disto, entendo que por corrida real se entende um teste online, onde vários EAs estão a decorrer e cada um está directamente agarrado ao seu próprio símbolo. Se é a isso que se refere, então uma pergunta. Porque é que precisamos de sincronização de barras neste caso, se cada Expert Advisor está localizado no seu próprio símbolo? Talvez, a sincronização de barras neste caso seja necessária quando o sistema de comércio é concebido de tal forma que uma decisão é tomada com base em vários símbolos ao mesmo tempo, pelo que as barras sobre estes vários símbolos devem ser formadas.
É aproximadamente como isto.
E aqui pode ver que não leu cuidadosamente o primeiro post do fio. Não com eventos temporizados, mas com OnChartEvent(). Ou é um erro de impressão?
Porque deveria ser? Tem aí o OnTimer como o terceiro número. Já foi citado sobre este assunto: basta-lhe implementar um método que execute correctamente o teste. Tem-na. Esta é a função OnTimer () com um intervalo mínimo. Por isso, deve ter algo mais em mente.
Existe um - EURUSD, mas o Expert Advisor negoceia no EURUSD a partir do gráfico GBPUSD. E os resultados são identicamente errados.
Se for importante para si, recomendo ainda assim que pergunte aos criadores qual é o análogo do ficheiro fxt em 5. Já escrevi que muito provavelmente são geradas diferentes bases de carrapatos para diferentes testes.