FORTES Por favor, ajude - página 9

Novo comentário
 
komposter:

Qual é a diferença entre "não" e "não pronto" para o programa (e o programador)?

Se os dados não estiverem prontos, haverá um erro.

Ou talvez estas informações também não estejam disponíveis instantaneamente, e é por isso que não são mostradas.

E a fim de evitar "entrar" no servidor.

Além disso, você é nosso "leitor"... Pergunta:

Por que eles constroem as séries cronológicas se os dados estão prontos ( CopyTime(símbolo,período,primeiro_data+PeriodoSegundos(período),1,vezes) )?

Если мы успешно прошли все проверки, то сделаем последнюю попытку обойтись без обращения к торговому серверу. Сначала узнаем начальную дату, для которой доступны минутные данные в формате HCC.
Запросим это значение функцией SeriesInfoInteger() с модификатором SERIES_TERMINAL_FIRSTDATE и опять сравним со значением параметра start_date.

   if(SeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date))
     {
      //--- there is loaded data to build timeseries
      if(first_date>0)
        {
         //--- force timeseries build                                            
         CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);
         //--- check date
         if(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date))
            if(first_date>0 && first_date<=start_date) return(2);
        }
     }
 
MigVRN:
Isso mesmo - ele carrega e prepara o que está lá. Mas devido ao fato de que qualquer atraso no indicador retarda o bate-papo com tudo o que pende sobre ele - nós o fizemos nos indicadores se a série não estiver pronta no momento da chamada - a função retornará um erro e INICIALIZARÁ a preparação dos dados. Depois de um tempo, ele não retornará mais um erro. Isto é o que está acontecendo em seus registros.

MigVRN!

Chukcha relê a ajuda e NÃO tem que concordar com você.

"É isso mesmo -carrega e prepara o que está lá".

Esta é sua especulação....

Mas a ajuda diz que a função SeriesInfoInteger com identificadorSERIES_TERMINAL_FIRSTDATE

Deve retornar:

SERIES_TERMINAL_FIRSTDATE

Primeira data na história por símbolo no terminal do cliente, independentemente do período

Não deve preparar nada!

Há dados no histórico do terminal - obtenha a data.

Não - ele retorna "0".

 
Um novo dia e redondo e redondo novamente.
 
barabashkakvn:
Um novo dia e redondo e redondo novamente.
Mostrar na referência, algo OUTRO
 
papaklass:
Preparar os dados e trabalhar com eles. Você pode dizer 150 vezes que algo está errado, e obter 150 respostas sobre o que fazer. É o seu trabalho, então cuide de si mesmo!

Obrigado, mas você sabe muito bem que TUDO tem que ser provado.

SD acha que retornar 0, quando os dados estão presentes, não é um erro de sua função.

Se assim for, DEVE ser escrito na documentação!

 

Mikalas:

Deveria, não deveria - é só disso que falamos. Bem, você pode ver por si mesmo como funciona :)

A única coisa com a qual posso concordar é que não está muito claro quais dados estão prontos A UMA VEZ (disponíveis a qualquer momento) e quais dados o terminal prepara quando você os acessa.

I(!) entendo que ao acessar quaisquer dados de série temporal (tempo e preço, número de barras, enumeraçãoENUM_SERIES_INFO_INTEGER, ou talvez eu tenha esquecido algo mais), os dados não estão prontos de uma só vez.

Para evitar tais situações, está escrito na ajuda:

Como o programa mql5 pode acessar dados por qualquer símbolo e período de tempo, existe a possibilidade de que os dados de um período de tempo necessário ainda não tenham sido gerados no terminal, ou que os dados de preços necessários não estejam sincronizados com o servidor comercial. Neste caso, o tempo de espera de prontidão dos dados é difícil de prever.

Algoritmos que utilizam ciclos de espera pela prontidão dos dados não são a melhor solução. A única exceção neste caso - scripts, porque não têm outra escolha de algoritmo, devido à falta de processamento de eventos. Para indicadores personalizados, tais algoritmos, assim como quaisquer outros loops de espera, não são fortemente recomendados, pois levam à interrupção do cálculo de todos os indicadores e outros processamentos de dados de preços para este símbolo.

Para Consultores Especialistas e indicadores personalizados, é melhor usaro modelo de processamentobaseado em eventos. Se o processamento de eventos OnTick() ou OnCalculate() não tiver conseguido obter todos os dados necessários das séries temporais necessárias, você deve deixar o manipulador de eventos, esperando ter acesso aos dados durante a próxima chamada do manipulador.

 
MigVRN:

Deveria, não deveria - é só disso que falamos. Bem, você pode ver por si mesmo como funciona :)

A única coisa com a qual posso concordar é que não está muito claro quais dados estão prontos A UMA VEZ (disponíveis a qualquer momento) e quais dados o terminal prepara quando você os acessa.

I(!) entendo que ao acessar quaisquer dados de série temporal (tempo e preço, número de barras, enumeraçãoENUM_SERIES_INFO_INTEGER, ou talvez eu tenha esquecido algo mais), os dados não estão prontos de uma só vez.

Para evitar tais situações, está escrito na ajuda:

Como o programa mql5 pode acessar dados por qualquer símbolo e período de tempo, existe a possibilidade de que os dados de um período de tempo necessário ainda não tenham sido gerados no terminal, ou que os dados de preços necessários não estejam sincronizados com o servidor comercial. Neste caso, o tempo de espera de prontidão dos dados é difícil de prever.

Algoritmos que utilizam ciclos de espera de prontidão de dados não são a melhor solução. A única exceção neste caso - scripts, porque não têm outra escolha de algoritmo, devido à falta de processamento de eventos. Para indicadores personalizados, tais algoritmos, assim como quaisquer outros loops de espera, não são fortemente recomendados, pois levam à interrupção do cálculo de todos os indicadores e outros processamentos de dados de preços para este símbolo.

Para Consultores Especialistas e indicadores personalizados, é melhor usaro modelo de processamentobaseado em eventos. Se durante o processamento dos eventos OnTick() ou OnCalculate() você não obteve todos os dados necessários das séries de tempos necessárias, você deve sair do manipulador de eventos, esperando ter acesso aos dados durante a próxima chamada do manipulador.

Andrew!

Não sei quanto a você, mas trabalho com documentação há muitos anos.

Veja, a partir da documentação que segue, como I(!) entendeu.

1. Vamos verificar se há dados do histórico do símbolo no terminal (SérieInfoInteger com o identificadorSERIES_TERMINAL_FIRSTDATE)

Talvez, não estou discutindo sobre isso, ele constrói e inicializa algo.

2. Nenhum dado (retorna uma data de início do histórico vazia) - vai para o servidor para obter dados.

Se houver uma data, construímos o prazo especificado usando a funçãoCopyTime(símbolo,período,primeiro_data+PeriodoSegundos(período),1,vezes);

4. Verificamos o início das séries cronológicas com a data dada(SérieInfoInteger(símbolo,período,SÉRIE_FIRSTDATE,primeira_data).

Está escrito na documentação.

Mas quando eu(!) peço dados do histórico por símbolo(não por série cronológica!!!!) no terminal, que estão EXATAMENTE lá

função retorna "0".

Você acha que isto é CERTO?

 
Mikalas:

MAS, quando eu(!) peço dados do histórico por símbolo(não pela série temporal!!!!) no terminal, que está EXATAMENTE lá

a função retorna "0".

Você acha que isto é CERTO?

Os dados (não preparados) estão em disco. Os dados (preparados) podem estar no bate-papo adjacente. Mas não há dados preparados sobre o bate-papo que está executando a indireção. Portanto, há um erro. Está correto. Mas não é conveniente :)

Embora eu mesmo não goste de tais perguntas - é crítico para você solicitar os dados do indicador para os caracteres adjacentes? (levando em conta o que está escrito na ajuda e meu exemplo - como um indicador pode retardar a execução do Expert Advisor e do chat). Você pode contornar todas essas dificuldades...

 
papaklass:

Você está pedindo "FIRSDDATE", não dados. A data provavelmente está lá, mas os dados podem estar faltando devido à economia. Por que bombear dados para todos os caracteres se eles não estão sendo usados no momento. Os desenvolvedores tomaram o caminho racional de bombear os dados somente quando o usuário acessa esses dados. Esta é a abordagem normal. Você, trabalhando com o terminal, deve SABER isto e agir de acordo.

Em vez de perder seu tempo em trocas, você está preso a coisas elementares e está perdendo seu tempo. Poupe seu tempo. :)

Os robôs estão trocando por mim, não estou em casa no momento...

E eu preciso de um indicador só para melhorar minha negociação :)

 
Mikalas:

Andrei!

Não sei quanto a você, mas trabalho com documentação há muitos anos.

Veja, a partir da documentação que se segue, como entendo I(!).

1. Vamos ver se há dados do histórico do símbolo no terminal (SérieInfoInteger com identificadorSERIES_TERMINAL_FIRSTDATE)

Talvez, não estou discutindo sobre isso, ele constrói e inicializa algo.

2. Nenhum dado (retorna uma data de início do histórico vazia) - vai para o servidor para obter dados.

Se houver uma data, construímos o prazo especificado usando a funçãoCopyTime(símbolo,período,primeiro_data+PeriodoSegundos(período),1,vezes);

4. Verificamos o início das séries cronológicas com a data dada(SérieInfoInteger(símbolo,período,SÉRIE_FIRSTDATE,primeira_data).

Está escrito na documentação.

Mas quando eu(!) peço dados do histórico por símbolo(não por série cronológica!!!!) no terminal, que estão EXATAMENTE lá

função retorna "0".

Você acha que isto é CERTO?

Leia a documentação com mais cuidado, não de forma seletiva. A presença de dados do histórico no disco não significa "está definitivamente lá" para o terminal. Neste caso (quando acessado pelo indicador), as funções só funcionam com o cache de timeseries na memória. Isso significa que o acesso à memória síncrona é realizado e, se não houver lá uma série de horas preparadas, a data SERIES_FIRSTDATE (do primeiro elemento da série) não será devolvida. Mas, é claro, o pedido inicia o carregamento da preparação de séries de tempos em memória.

A solicitação SERIES_TERMINAL_FIRSTDATE está conectada com a inicialização e sincronização do banco de dados com o servidor, portanto, a primeira chamada não funcionará imediatamente de qualquer forma.

Em princípio, a capacidade de obter o histórico necessário é verificada usando SERIES_SERVER_FIRSTDATE . Isto é, é claro que você pode contar com X iterações de pedido de histórico, mas se o terminal confirmar a presença do histórico através de SERIES_SERVER_FIRSTDATE, então a disponibilidade de dados de séries de tempos relevantes é apenas uma questão de tempo (sincronização do banco de dados m1 com o servidor e geração de séries de tempos).

12345678910111213141516...31
Novo comentário