Servicedesk: preguiça, autismo ou relutância em admitir erros? Complementar os gráficos com velas não nativas.
Foi esta a questão que levantou há um mês atrás? https://www.mql5.com/ru/forum/1111/page878#comment_344461
FiftyStars:
...A história é o que é. Não temos uma história minuciosa. Para sua conveniência, a história mais profunda é representada por barras diárias.
Se não for conveniente para si, limite o uso deste histórico manualmente.
A essência da resposta já era conhecida na altura(https://www.mql5.com/ru/forum/1111/page878#comment_344518):
Mas receio que (a resposta) seja algo do género: "O próprio programador pode calcular a data limite e limitar a profundidade da história solicitada.
Contactei o Service Desk com um problema com a anexação de velas TF mais altas a gráficos TF mais baixos quando não há histórico de TFs mais baixos. Isto significa que quando vamos ao início da história no gráfico M1, vemos velas não de M1, mas de D1, ou mesmo de W1. Devido a esta adesão, a função SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) devolve não a data em que o histórico da M1 termina, mas a data da primeira barra fora do prazo, ou seja, o prazo especificado não afecta o resultado.
...
SERIES_BARRAS_COUNT retorna o número de velas (barras), pertencentes a um determinado símbolo e período de tempo
SERIES_FIRSTDATE devolve a data da primeira vela (barra) aberta, que pertence a um certo símbolo e período de tempo.
Mais informação
...
As funções funcionam correctamente.
O que vê é uma consequência do seu pedido de qualidade de história anterior.
A história é o que ela é. Não temos uma história minuciosa. Para sua conveniência, a história mais profunda é representada por barras diárias.
Se não for conveniente para si, limite o uso deste histórico manualmente.
Esta é uma desculpa franca, o programador não pode prever todas as opções de morder a história, por isso não pode prescrever a função de procurar a primeira data da TF. Hoje são assim, e amanhã terão novas voltas e reviravoltas, e sem o conhecimento da MQ, por exemplo, negociar vai estragar alguma coisa.
E porque precisamos dele quando existe uma função padrão, mas o facto de dar o tempo para anteontem já é um erro.
Aqui está o cerne do problema para o programador:
Precisamos de procurar variantes dos critérios segundo os quais esta barra pode ser considerada a primeira barra da TF seleccionada, e todas as anteriores - a adição da TF mais antiga. Pode haver lacunas em bares como uma barra falhada (isto é uma consequência directa do formato de gravação de barras escolhido pela MQ) ou lacunas em bares como o fim-de-semana/férias. E numa tal cacofonia de sinais não é claro como determinar que esta barra é a barra certa.
Qual é a essência do problema para a MQ: (se quisermos dizer que o vão resolver)
Quando a história é cosida a um ficheiro encriptar dados sobre os pontos de costura (não há muitos, no máximo 21 pelo número de TF, na prática, há 2-3), a questão é resolvida. Em seguida, escrever uma função para ler esta informação protegida e enviá-la ao utilizador através de pedido.
Obrigado, não se decidam pelos comerciantes.
Que cabeça fresca foi fazer tal movimento depois de sexta-feira - inserir as barras mais antigas no período de tempoM1 ?
Quem lhe deu mesmo o direito - de inverter muitos anos de princípios bem estabelecidos?
Se não estiver confortável com ela, limite o uso desta história manualmente.
Obrigado, não se decidam pelos comerciantes.
Que cabeça fresca foi fazer tal movimento depois de sexta-feira - inserir os bares sénior no prazoM1 ?
Quem lhe deu o direito de reverter muitos anos de princípios estabelecidos?
Alex, não exagere, a colagem de TF foi necessária para calcular correctamente todas as outras TFs, depois de terem decidido calcular todas as TFs da M1.
Se se lembrar, deixe-nos calcular até 21 TFs (incluindo as não-padronizadas).
Não se falou disso mais do que uma vez. Não voltaremos ao antigo sistema de armazenamento de cada TF separadamente, compreende.
Mas o facto de a implementação acrescentar mais problemas para os programadores é um facto. E a questão é simples de resolver, mas não, nós sabemos melhor o que você precisa :(
por isso é isso que me interrogo.
Если вам это не удобно - ограничивайте использование этой истории вручную.
Alex não exagera, a colagem de TF foi necessária para calcular correctamente todas as outras TFs, após ter sido tomada a decisão de calcular todas as TFs da M1.
É resolvido através da definição de um identificador no histórico e ao ler, se os dados para a barra não pertencerem a M1, então não será produzido em M1, não pertencerá a M5, então não será produzido em M5. Ou sim... devemos escrever a data de junção das barras do período actual com as do período superior no FirstDate e o utilizador terá uma possibilidade real de saber de que data começar a processar, de modo a não apanhar barras mais antigas.
A situação é certamente idiota.
Não se pode desenhar tais gráficos, nem devolver tais valores a partir de funções.
Se queres construir a partir da M1, constrói-a. Não é suficiente M1 - descobrir como sair dela, mas não às nossas custas.
(todos endereçados, claro, à MQ)
- www.mql5.com
Concordo, é uma parvoíce.
E se há separadores periódicos, é uma beleza.
E tem de o torcer no código ((.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Contactei o Service Desk com um problema com a anexação de velas mais altas a gráficos TF baixos quando não há histórico de TFs mais baixos. Isto significa que quando vamos ao início da história no gráfico M1, vemos velas não de M1, mas de D1, ou mesmo de W1. Devido a esta adesão, a função SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) devolve não a data em que o histórico da M1 termina, mas a data da primeira barra fora do prazo, ou seja, o prazo especificado não afecta o resultado. Quando me foi pedido, recebi uma desculpa de que é conveniente para os utilizadores e a data de corte para cada período de tempo de cada símbolo deve ser definida manualmente. Desculpe-me, mas esta função não deveria ser executada pela função SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x), e como é que aSERIES_FIRSTDATE diferedaSERIES_FIRSTDATEna TF M1 especificadase o resultado for o mesmo?
Que disparate é este? Quem e porquê é conveniente? Ninguém quer ver as velas W1 nos gráficos M1. Bem, excepto para masoquistas ...
Chego à seguinte conclusão: ou os criadores são autistas (vivem no seu mundo, onde o acima e o abaixo são a norma, ou melhor, não a norma, mas o trabalho é 5 +), ou são demasiado preguiçosos para o corrigir, ou o princípio de "Como é que nunca estamos errados, somos todos bons". Bem, também há variantes: eles brincam, não sabem como consertá-lo.
Aqui estão as capturas de ecrã, pode ver claramente a linha de união da história de diferentes TFs:
https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png
https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png
https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png
https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png
https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png
pergunta 1:
Versão e taxa de bits do terminal
Construir 712 x86
Descrição do problema.
Os dados históricos de pequenos períodos de tempo são continuados por dados históricos de períodos de tempo maiores. Significa, por exemplo, que a história do EURUSD na M1 termina em ~04.01.1999, e no lado esquerdo do gráfico M1 está anexado o gráfico D1 para o período anterior a 04.01.1999.
Pode vê-lo nas imagens anexas. Devido a isto, a função SeriesInfoInteger com o parâmetro SERIES_FIRSTDATE funciona de forma incorrecta. A função retorna a primeira data de toda a história (incluindo os períodos D1, W1 e MN1) em vez da primeira data do período do símbolo.
A sequência de acções
Percorrendo o gráfico até ao início da história
O resultado obtido
Continuação do gráfico com dados históricos de períodos de tempo maiores.
Resultado esperado
Restrição do gráfico no final do histórico dos dados sobre o período de tempo dado.
Informação adicional
Pedido 2:
Versão terminal e taxa de bits
construir 712 x86
Descrição do problema
Descrição na documentação:
SÉRIE_BARS_COUNT.
Número de barras por símbolo-período no momento
longo
SERIES_FIRSTDATE
A primeira data para o período do símbolo actual
data/hora
Devido à adesão da história para a TF inferior, no caso da ausência da história durante um período de tempo específico na TF inferior, e a presença da história para o mesmo período na TF maior, o gráfico, por exemplo, M1 mostra as velas do gráfico de D1.
Estará a ser preparada uma solução para este problema? Existe alguma solução para este problema neste momento, para além da restrição manual?
Sequência de acções
Utilização destas funções
O resultado obtido
SERIES_BARRAS_COUNT em prazos baixos (até D1) devolve o número de velas (barras), pertencentes ao símbolo e ao prazo, mais o número de velas do prazo maior mais próximo, para o qual os dados históricos estão disponíveis
SERIES_FIRSTDATE em prazos baixos (até D1) devolve a data de abertura da primeira vela (barra) da história.
O resultado esperado
SERIES_BARRAS_COUNT retorna o número de velas (barras), pertencentes a um determinado símbolo e período de tempo
SERIES_FIRSTDATE devolve a data da primeira vela (barra) aberta, que pertence a um símbolo e a um período de tempo especificados.
Mais informação
...
As funções funcionam correctamente.
O que vê é uma consequência do seu pedido de qualidade de história anterior.
A história é o que ela é. Não temos uma história minuciosa. Para sua conveniência, a história mais profunda é representada por barras diárias.
Se não for conveniente para si, limite o uso deste histórico manualmente.