O problema da transferência do MT4 para o MT5. Ou, mais precisamente, a incapacidade de executar alguns algoritmos no MT5 sem errar. - página 7
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 absurdo está em organizar sua própria cópia dos dados, que já está disponível no terminal.
Há muitos desses disparates. Quando o MT4 foi lançado em agosto de 2005, o indicador ZigZag apareceu. Há ali muitos erros. Em um caso, ele poderia pendurar o terminal no mercado rápido naquele momento. E muitas vezes apresentava extremos no ar, não relacionados a mínimos/máximos de barras.
Em um post o desenvolvedor deste ziguezague disse que isto - (por favor, não leve nenhuma emoção adiante) é uma manifestação de fuzzy logic........
Mas até agora, 14 anos se passaram desde o lançamento do MT4, no indicador do ziguezague há um parâmetro - Desvio - que não produz nenhuma ação. Isto é, não importa o valor deste parâmetro que você definir, o desenho do ziguezague no gráfico não mudará.
Muitos programas se baseiam neste indicador. A maioria dos desenvolvedores inclui este parâmetro em seus programas. É um parâmetro inútil. Os desenvolvedores mostram uma indiferença fantástica por ela. Este parâmetro, a propósito, come recursos informáticos.
Houve muitos desses momentos em várias outras ocasiões.
Vou continuar.
Aqueles extremos em ziguezague pendurados no ar são exatamente da mesma natureza do que temos quando acessamos as séries de tempo.
É que o acesso às séries temporais não foi negado no MT4. Algumas funções não funcionaram corretamente lá (talvez ainda funcionem agora). Eu tinha uma explicação para meu próprio uso interno. Também fiz uma forçada por minha conta. E tudo começou a funcionar sem erros, sem carga de CPU. Mesmo a saída de várias dezenas de ziguezagues nos gráficos não fez com que o terminal ficasse pendurado.
Se tudo funcionasse, não haveria um milhão de tópicos dedicados a este problema.
A lógica acabou se revelando mais complicada do que os usuários do terminal estão dispostos a lidar.
E deve haver erros, mas os desenvolvedores não têm tempo para procurá-los, e ninguém quer reproduzi-los e comprová-los entre os usuários.
Andrei, sugiro que comecemos com o que temos. E já que temos o que você está falando, é melhor falar sobre isso, ou evitá-lo?
Penso que existem problemas suficientes, mas em vez de falar deles de ramo para ramo (o que também é útil - às vezes eles são consertados), mas fazer o trabalho de volta.
E eu sugeri uma boa opção - armazenar as séries de horários necessárias no momento de sua disponibilidade total. E depois receber todos os dados necessários de séries de horários prontas e sempre disponíveis. E apenas complementá-los com novos dados. Quando estão disponíveis - lentamente e não necessariamente no momento em que você precisa deles.
Pelo menos desta forma as coisas vão avançar. E as conversas podem ser deixadas para mais tarde - quando não há nada a fazer.
Vou continuar.
Aqueles extremos em ziguezague pendurados no ar são exatamente da mesma natureza do que temos quando acessamos as séries de tempo.
É que o acesso às séries temporais não foi negado no MT4. Algumas funções não funcionaram corretamente lá (talvez ainda funcionem agora). Eu tinha uma explicação para meu próprio uso interno. Também fiz uma forçada por minha conta. E tudo começou a funcionar sem erros, sem carga de CPU. Mesmo a saída de várias dezenas de ziguezagues para os gráficos não fez com que o terminal ficasse pendurado.
Se o acesso às séries temporais for negado, isso significa que está na fase de sincronização. Você precisa esperar até o próximo tique.
Em sua situação - melhor para o cache de timeseries - elas estarão sempre disponíveis sem esperar, e à primeira solicitação.
Cache quando o indicador começa - quando há tempo para "esperar pela sincronização" e enquanto se espera para solicitar dados para as próximas séries cronológicas.
Andrei, estou sugerindo que devemos ir com o que temos. E já que temos o que você está falando, é melhor falar sobre isso, ou dar a volta a isso?
Penso que existem problemas suficientes, mas em vez de falar deles de ramo para ramo (o que também é útil - às vezes eles são consertados), mas fazer o trabalho de volta.
E eu sugeri uma boa opção - armazenar os horários necessários no momento de sua total disponibilidade. E ainda - para receber todos os dados necessários de séries de tempos prontas e sempre disponíveis. E apenas complementá-los com novos dados. Ao mesmo tempo, quando estão disponíveis - não apressadamente, e não necessariamente no momento em que são necessários.
Pelo menos desta forma as coisas vão avançar. E as conversas podem ser deixadas para mais tarde - quando não há nada a fazer.
Então, já é mais eficaz fazer um exemplo reprodutível para que os desenvolvedores possam consertar.
Andrei, estou sugerindo que devemos ir com o que temos. E já que temos o que você está falando, é melhor falar sobre isso, ou dar a volta a isso?
Penso que existem problemas suficientes, mas em vez de falar deles de ramo para ramo (o que também é útil - às vezes eles são corrigidos), faça o trabalho de volta.
E eu sugeri uma boa opção - armazenar as séries de horários necessárias no momento de sua disponibilidade total. E depois, para receber todos os dados necessários de séries de tempos prontas e sempre disponíveis. E apenas complementá-los com novos dados. Ao mesmo tempo, quando estão disponíveis - não apressadamente, e não necessariamente no momento em que são necessários.
Pelo menos desta forma as coisas vão avançar. E as conversas podem ser deixadas para mais tarde - quando não há nada a fazer.
E por que os desenvolvedores do terminal não podem fazer isso? De qualquer forma, não há acesso às séries de horários no momento da atualização. Que todos tenham acesso a isto, digamos, a história em cache. Que diferença isso faria? Ou seja, para que nunca houvesse uma interrupção no acesso. Bem, talvez houvesse alguns atrasos na barra zero. O resto da história estaria sempre disponível.
Eu sugeri uma boa opção - armazenar as séries de horários necessárias no momento de sua disponibilidade total. E então - obter todos os dados necessários a partir de séries de horários prontas e sempre disponíveis. E apenas complementá-los com novos dados.
Esta é uma variante ruim, você tem que repetir inteiramente a lógica de construção e sincronização de séries temporais no terminal - um novo tick veio, a sincronização não estava terminada... então uma falha de conexão
ZS: Sim, e por que fazer isso? - Não sei quantos na vida, tenho um celular, um carro e até mesmo uma carteira com apenas um, mas muitos casos na vida? - precisa de seguro? .... "Three tape recorders, three foreign film cameras, three cigarette cases domestic, casaco... camurça... Three. Casacos")))
Se o acesso às séries temporais for negado, isso significa que está em sincronia. Você tem que esperar até o próximo tique.
Mas é necessário parar o programa MQL em qualquer lugar e sair do terminal até o próximo tick ... Eu periodicamente sugiro algo como em Delphi "Abort() ou Halt()" - obter um erro de acesso de série temporal uma vez - éum erro crítico que não faz sentido lidar muitas vezes - não vai funcionar até que o terminal estabeleça comunicação com o programa MQL de qualquer maneira )))
SZZ: Eu não crio este erro (erro de acesso a timeseries) - ele é criado pelo terminal, mas todos os programadores MQL devem estar prontos para depurar o erro gerado pelo terminal... ( quando o código consiste em algumas centenas de linhas ) é fácil de jogar, mas quando o código é grande e é conveniente usar o acesso a timeseries de diferentes seções do programa - e requer 999 maneiras de sair de qualquer seção e não perder os cálculos anteriores... - Sim, é possível, mas requer um plano claro (algoritmo) pelo qual o código fonte será escrito ... E se o código fonte for refinado através da adição de funções prontas (classes)? - ou seja, toda vez que você tiver que descobrir o que está dentro... uma tarefa geralmente demorada para grandes projetos para fornecer tudo, imho
Se um programa foi construído há 14 anos, traduzi-lo por um novo método de projeto é mais fácil do que atirar no próprio pé. E depurar os múltiplos links também é difícil. A verificação da acessibilidade aos prazos dá sérios atrasos se não houver acesso. Seria bom seas construções gráficas automáticas estivessem habilitadas. A reconstrução em modo automático é um fenômeno pouco freqüente. Você pode até mesmo não notar atrasos aqui. Mas neste caso, também, quando o acesso às séries temporais é interrompido, as construções gráficas às vezes são produzidas de forma truncada. Alguns dos elementos têm tempo para serem construídos e outros não. Ou, a filtração fractal truncata alguns tf.
***
Se um programa foi criado há mais de 14 anos, traduzi-lo usando o novo método de design é mais fácil do que dar um tiro no pé. E depurar os múltiplos links também é difícil. A verificação da acessibilidade aos prazos dá sérios atrasos se não houver acesso. Seria bom se as construções gráficas automáticas estivessem habilitadas. A reconstrução em modo automático é um fenômeno pouco freqüente. Você pode até mesmo não notar atrasos aqui.
Mas o problema é quando o ajuste é realizado através de interface gráfica. O usuário pressiona o botão e... tem que esperar pelo próximo tique. Ou o usuário pressiona o botão várias vezes até que ocorra a resposta desejada. Qual é a resposta do usuário...? -***
E não há tais problemas no MT4.
Eu o entendo muito bem, então decidi apoiar a discussão
iClose()...iXXX() funciona para acessar séries de tempo - ótimo!
Que sejam funções síncronas, ou seja, o acesso a séries temporais será mais longo, mas garantido no nível do terminal. Ou os desenvolvedores da U.V. devem adicionar a diretiva de pré-compiladores que dará um tique no programa MQL somente se o terminal estiver pronto para acessar dados históricos (OHLC) - sem tique se não estiver.
....
mas o único objetivo é se livrar de infinitas verificações de prontidão de gráficos OHLC, este problema foi resolvido desde o aparecimento do MT5 apenas no nível de verificações dentro do programa MQL, é um processo demorado e na minha opinião os usuários esperam que o terminal receba os dados da série temporal sem problemas e garantidos a qualquer momento, em qualquer seção de código
esta é uma má opção, você precisa repetir completamente a lógica de construir e sincronizar séries de tempos no terminal - depois veio um novo tick, depois a sincronização não terminou...depois uma falha na conexão
ZS: Sim, e por que fazer isso? - Não sei quantos na vida, tenho um celular, um carro e até mesmo uma carteira com apenas um, mas muitos casos na vida? - precisa de seguro? .... "Three tape recorders, three foreign film cameras, three cigarette cases domestic, casaco... camurça... Three. Casacos")))
Tudo bem! Mas o programa MQL deve parar os cálculos em qualquer lugar e sair do terminal até o próximo tick... Ocasionalmente sugiro algo como em Delphi "Abort() ou Halt()" - você recebe um erro acessando séries de tempo - é um erro crítico, que não faz sentido processar muitas vezes - de qualquer forma, até o terminal estabelecer interação com o programa MQL "não adianta" )))
SZZ: Eu não crio este erro (erro de acesso a timeseries) - ele é criado pelo terminal, mas todos os programadores MQL devem estar prontos para depurar o erro gerado pelo terminal... ( quando o código consiste em algumas centenas de linhas ) é fácil de jogar, mas quando o código é grande e é conveniente usar o acesso a timeseries de diferentes seções do programa - e requer 999 maneiras de sair de qualquer seção e não perder os cálculos anteriores... - Sim, é possível, mas requer um plano claro (algoritmo) pelo qual o código fonte será escrito ... E se o código fonte for refinado através da adição de funções prontas (classes)? - ou seja, toda vez que você tiver que descobrir o que está dentro... ...tarefa demorada para grandes projetos, imho
Se o programa for executado por um clique do mouse, não importa se existe um acesso ou não - você tem que reagir. Você pode escrever muito sobre como tudo é mal feito, mas neste caso é melhor ter seu próprio cache, do qual você pode sempre acessar sob demanda.
Imagine o programa, que em vez de dar algo sobre os dados históricos longos calculados por clique do mouse, diz - vá fumar - eu recebo os dados atuais, que você não precisa agora, e reconstruo as séries temporais...
Não importa como, se você tiver que se contentar com o que você tem, é melhor dar o que está no cache e depois reconstruí-lo depois de desbloquear o acesso à série temporal.