Erros, bugs, perguntas - página 2573

 

Oh, sim, então não tem de se preocupar com sobrecarga de disco.
O que me surpreende é usar variáveis globais de terminal (se é disso que se trata) para salvar grandes conjuntos de dados.
É uma muleta arrepiante, não é?

Ok, as variáveis em si, mas há os seus nomes de string, que também devem ser armazenados e ainda fazer cada vez que uma string procura por acesso a esta variável, para não mencionar o único tipo duplo, que pode ser armazenado. Claro, pode utilizar a união, mas a sua utilização não é gratuita.

É muito mais correcto implementar a poupança de forma independente através de recursos de qualquer matriz de dados com auto-gravação em disco ou quando ocorre um evento deinit

 
Nikolai Semko:

As variáveis em si são boas, mas existem nomes de cordas, que também devem ser armazenados e ainda fazer sempre uma pesquisa de cordas para acesso a esta variável, para não mencionar o único tipo duplo, que pode ser armazenado. É evidente que podemos utilizar a união, mas a sua utilização também não é livre.

Tive uma ideia e desejo de utilizar variáveis globais, mas decidi salvá-las no disco da maneira antiga, especialmente agora comecei a escrever código correctamente - os dados são armazenados em estruturas, e é possível descarregar estruturas no disco com um clique - FileWriteStruct().



portanto, as variáveis globais "devem ser utilizadas exactamente ao contrário" - os dados devem ser armazenados no nome da variável global e o checksum em dobro com Base64 - tudo está pronto em CryptEncode(), e idealmente deve ser Base85 ( Ascii85 ) ou visto algures no código fonte do githab Base128

e se não me engano, o nome da variável global no terminal é 256 caracteres? a eficiência da Base64 é ligeiramente superior a 60% ( tamanho), outros métodos de codificação têm maior eficiência - pode armazenar 160-180 bytes numa variável global

Embora tenha de determinar os dados utilizando o prefixo, mas em geral, funcionará - tanto mais que as variáveis globais são raramente utilizadas - todos os nomes são essencialmente livres

 
Igor Makanu:

Tive uma ideia e um desejo de utilizar variáveis globais, mas decidi salvá-las no disco da forma antiga, especialmente agora que comecei a escrever códigos da forma mais correcta possível - Armazeno dados em estruturas, e posso descarregar estruturas no disco com um clique - FileWriteStruct().



portanto, as variáveis globais "devem ser utilizadas exactamente ao contrário" - os dados devem ser armazenados no nome da variável global e o checksum em dobro com Base64 - tudo está pronto em CryptEncode(), e idealmente deve ser Base85 ( Ascii85 ) ou visto algures no código fonte do githab Base128

e se não me engano, o nome da variável global no terminal é 256 caracteres? a eficiência da Base64 é ligeiramente superior a 60% ( tamanho), outros métodos de codificação têm maior eficiência - pode armazenar 160-180 bytes numa variável global

Embora tenha de determinar os dados utilizando o prefixo, mas, em geral, tudo funcionará - tanto mais que as variáveis globais são raramente utilizadas - todos os nomes são essencialmente livres

Ainda assim, para chegar a uma variável, tem de passar pelos checksums até encontrar a variável certa. E se houver muitas variáveis?
Ou pode seguir a sequência de variáveis e atribuir-lhes índices. Mas isto é absolutamente inútil, porque é mais fácil escrever uma classe para guardar dados
 
Nikolai Semko:
é mais fácil escrever uma classe de poupança de dados

A turma é exposta, incluindo exemplos. Os programadores introduzirão novas funcionalidades que permitem, já sem a escrita de invólucros em torno de recursos, transferir dados.

Asvariáveis globais são utilizadas para bandeiras. É também conveniente ver sempre os seus valores - F3.

 
fxsaber:

A turma é exposta, incluindo exemplos. Os programadores introduzirão novas funcionalidades que permitem, já sem a escrita de invólucros em torno de recursos, transferir dados.

Asvariáveis globais são utilizadas para bandeiras. É também conveniente ver sempre os seus valores - F3.

Sim, eu fiz. Foi por isso que fiquei surpreendido.
Para controlo de valores concordo, então justificado.
 
Georgiy Merts:

Descobri que no meu modo de teste visual SymbolInfoTick() retorna um valor mas a série de tempos Close[0] tem um valor diferente.

O erro é meu? Estou a fazer algo de errado?

Parece que deveriam ser os mesmos valores:

Normalmente a diferença é de 1-2 pontos, mas em movimentos bruscos pode ser mais.

É apenas eu?

Por agora tomei as séries cronológicas como "mais correctas". Se se verificar que SymbolInfoTick() dá um valor diferente de Close[0], então assumo que o valor correcto é Close[0] e deixo um spread como foi devolvido por SymbolInfoTick().

Mas, é interessante compreender, que preço é correcto, que preço é "procurado" por DC - SymbolInfoTick() ou Close[0].

Qual é o número de construção?

Build 2155 já deve ter sido corrigido - este bug foi corrigido na semana passada

 
Slava:

Qual é o número de construção?

Build 2155 já deve ter sido corrigido - eles corrigiram o bug na semana passada

Sim. E eu tenho 2085.

Compreendido, actualização.

P.S. Sim, os valores são os mesmos agora.
 
Slava:

Qual é o número de construção?

Build 2155 já deve ter sido corrigido - este bug foi corrigido na semana passada

Sabe alguma coisa sobre o assunto?
https://www.mql5.com/ru/forum/1111/page2571#comment_13285021
 
Aleksei Beliakov:
Sabe alguma coisa sobre o assunto?
https://www.mql5.com/ru/forum/1111/page2571#comment_13285021

Não deu nenhum detalhe para reproduzir

 
Slava:

Não forneceu quaisquer detalhes para reproduzir

Banal se imprimir os resultados destas funções em ontick, é pelo tempo 1970.01.01.01 pelo preço 0
Costumava ser tempo de bar ou tempo de preço.
Assim é agora.
iHigh(NULL,PERIOD_W1,0) в журнале будет 0
iTime(NULL,PERIOD_W1,0) в журнале будет 1970.01.01