Servicedesk: preguiça, autismo ou relutância em admitir erros? Complementar os gráficos com velas não nativas.

 

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

...

Equipa de Apoio2012.11.20 14:38
Estado:AbertoFechado

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.

 
FiftyStars: Servicedesk contactado...

Foi esta a questão que levantou há um mês atrás? https://www.mql5.com/ru/forum/1111/page878#comment_344461

FiftyStars:

Equipa de Apoio2012.11.20 14:38

...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.

 
FiftyStars:

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

...

Equipa de Apoio2012.11.20 14:38
Estado:AbertoFechado

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.

 
Para sua própria conveniência, a história mais profunda é representada por barras diárias.

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.

mas como ?
 
sergeev:



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?



mas como?

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.

Если вам это не удобно - ограничивайте использование этой истории вручную.

como?
 
Urain:

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.

Resolve-se definindo o identificador no histórico e ao ler se os dados para a barra não pertencem a M1, então não saem para M1, não pertencem a M5, então não saem para M5. Ou yes....write in FirstDate a data da fusão das barras do período actual com as barras do período superior e o utilizador terá uma oportunidade real de saber a partir de que data iniciar o processamento de modo a não apanhar as barras mais antigas.
 
FiftyStars:
É 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.
Escrevi sobre isso acima, sou demasiado preguiçoso para carregar novamente no teclado.
 

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)

Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования - Документация по MQL5
 
Que diabo.
 

Concordo, é uma parvoíce.

E se há separadores periódicos, é uma beleza.

os meus olhos !

E tem de o torcer no código ((.

Razão: