Erros, bugs, perguntas - página 689
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
Alex, porque não aceitamos o modelo multi-moeda como modelo de base e deixamos que aqueles que não precisam dele implorem aos CD para encurtar a sua história cortando as barras sincrónicas.
Se eu quisesse utilizar o terminal como um MQ multi-moeda, tê-lo-ia deixado numa base de moeda única e teria perdido o evento multi-moeda, daí todos os problemas que se seguiram.
o que é que os modelos ou modelos de teste têm a ver com isto?
O objectivo da plataforma é receber e armazenar claramente a informação inicial nos terminais na mesma quantidade que foi recebida pelo servidor.
Os criadores não podem dar qualquer informação imparcial! Há apenas tanta informação sobre carraças como há.
Se o modelo de teste multi-moeda implica uma barra a cada minuto, este não é um modelo do servidor, é um modelo do testador.
Se o modelo de indicadores de construção implica a presença de uma barra a cada minuto, não é um modelo do servidor, mas um modelo do trabalho do indicador
Não é preciso implorar aos programadores que mudem o servidor para se adaptar aos seus modelos de percepção ou testes da história, não é construtivo.
Se precisar do histórico de minutos em falta, tem de pedir às suas empresas de corretagem que adicionem as barras de cada minuto em falta ao seu histórico, com um único volume.
Peça ao seu corretor para contornar a muleta das Metaquotes? A mesma muleta aplica-se aos solteiros.
Precisa que o servidor armazene a hora de início da barra de minutos não em :00 segundos mas na hora da chegada do primeiro tick, por exemplo em :05 ou :24 ?
Se é tudo o que precisa e isso resolverá muitos problemas de teste - o terminal e a qualidade do seu testador irão melhorar muito? Será essa compensação de vários segundos crítica para os testes com várias moedas?
Não esquecer que o testador modela todos os preços dentro de um bar utilizando o volume do tick. Irá ganhar muito se o primeiro tick vier como veio, e todos os outros não vierem de todo como na vida real?
Se este turno não tem efeito sobre os próximos tiques, para que serve afinal o turno? Por causa do primeiro tick correcto?
Parece-me que sem um teste sobre a história real do tick - tendo em conta o tempo real do primeiro tick e modelando os subsequentes - é um benefício imaginário.
O que é que os modelos ou modelos de teste têm a ver com isto?
O objectivo da plataforma é aceitar e armazenar claramente a informação original nos terminais na quantidade que apareceu e veio para o servidor.
Os criadores não estão autorizados a dar nada! A quantidade de informação sobre carraças é a mesma que foi recebida - nem um byte mais, nem menos.
Se o modelo de teste com várias moedas implica que há uma barra em cada minuto, este não é um modelo do servidor, é um modelo do testador.
Se o modelo de indicadores de construção implica a presença da barra em cada minuto, não é um modelo de servidor, mas o modelo do indicador
Não vá implorar aos criadores que mudem o servidor para se adequar à sua percepção histórica ou modelos de teste, não é construtivo.
Se precisar do historial de minutos em falta, então deve pedir - os seus CDs, que acrescentem barras de cada minuto perdido ao seu historial, com volumes unitários.
Nós alteramos os factos para o curso de pensamento necessário :)
O servidor transmite carraças, onde vê o histórico das carraças?
Por outro lado, o terminal recebe o histórico, que é armazenado pelo servidor, mas porque é que se considera correcto armazenar o histórico no servidor neste formato e não numa barra sincrónica?
Porque é que o servidor em si não tem gerador de frequência ???
Porque é considerado correcto cortar barras por tempo, mas introduzir um gerador de frequência já não é correcto??
Vamos então livrar-nos completamente do tempo e mudar para cruzes e zeros. Basicamente, não existe aí qualquer conceito de tempo.
Quer que o servidor armazene a hora de início da barra de minutos não em :00 segundos, mas na hora do primeiro tick, por exemplo em :05 ou :24 ?
Não, não se trata disso. A única coisa a fazer é fazer o preço de abertura do bar corresponder ao preço que estava na conta real no momento da abertura do minuto. Isto é, temos de fazer com que o provador que mostra o preço de abertura do bar no minuto de abertura não minta.
Essa mudança de vários segundos é crucial para o teste de Expert Advisors com várias moedas?
Sim, é, porque causa uma significativa dessincronização. Por exemplo, cria uma situação de arbitragem quase constante entre vários símbolos relacionados, aos preços de abertura.
Não esquecer que o testador modela todos os preços dentro de um bar utilizando o volume do tick. Irá ganhar muito se o primeiro tick chegar como chegou e todos os outros não forem de todo como eram na vida real?
Muito mais do que foi - a sincronização será não só entre os preços de fecho, mas também entre os preços de abertura. Além disso, as barras multi-moeda serão sincronizadas, o que libertará uma enorme quantidade de recursos informáticos durante a optimização, que são agora gastos na mesma operação em cada passagem - sincronização.
Parece-me que sem um teste sobre a história real do tick - para ter em conta o tempo real do primeiro tick e simular os próximos - é um lucro imaginário.
A tarefa de armazenar a história de múltiplas moedas é muito semelhante à do armazenamento de vídeo. É necessário armazenar uma moldura de sincronização válida e guardar as alterações da mesma.
Actualmente não existe qualquer estrutura sincrónica, existem apenas linhas sincrónicas. Cada linha (par de moedas) armazena as suas alterações e mesmo as linhas não têm ponto de sincronização.
Não podemos dizer com segurança que o preço estava exactamente neste ponto (abertura do bar).
Uma vez que a abertura do bar foi em xx:yyy:00 e o tique de abertura foi em xx:yyy:12
Uma vez que a hora de abertura do bar era xx:yy:00 e o tique de abertura era xx:yy:12
Para o armazenar dessa forma, é necessário fazer um grande esforço para convencer os criadores de que é a coisa certa a fazer e todos irão beneficiar.
Mas é viável (refiro-me ao lado técnico). Basta convencê-los a reescrever o motor do servidor (e o terminal também) para armazenar e processar barras :)
Nesta situação, mais resistência (80%) estará na primeira fase de persuasão. E, depois disso, cabe aos progamadores.
Que Veles e Ganesh os ajudem
Não se pode dizer com segurança que neste momento (abertura do bar) o preço estava exactamente lá.
Porque a hora de abertura do bar era xx:yy:00 e o tique de abertura era xx:yy:12
Pode, se apenas visar preços de fecho. Mas para o fazer, precisamos de seguir o evento de encerramento minuto (não de bar), tomando Fechar[1] como o preço actual.
Tais soluções de trabalho são completamente artificiais, mas é uma solução de porta traseira.
Mesmo que os criadores alterem a situação, o preço Ask simulado continuará a dar uma dessincronização, tanto com análise real como com análise de múltiplas moedas no testador.
É, porque dá uma grave dessincronização. Por exemplo, cria uma situação de arbitragem quase constante entre vários símbolos interligados aos preços de abertura.
... O que não existe realmente, mas o testador cria a ilusão no testador de que a arbitragem existe.
Certo?
... que não existe realmente, mas o testador dá a ilusão ao testador de que a arbitragem existe.
Certo?
Muito bem. Não há arbitragem na vida real, e o testador mostra preços de arbitragem sobre dados históricos aparentemente exactos (não modelados) - preços de abertura.
Não é bom...
Aqui sempre senti no meu cérebro que a análise multimoeda deveria ser evitada, caso contrário teria um ancinho na testa. Parece que o evitei por uma razão.