Erros, bugs, perguntas - página 3038
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
Toda a questão é a razão entre "tempo de compressão/descompressão" e "espaço em disco ocupado".
Evidentemente, é possível encontrar uma solução melhor. É apenas um pouco mais complicado dentro de um terminal do que uma solução privada "para si".
Não se trata de zipar dados, mas de os comprimir logicamente para formar matrizes indexadas. O tempo de acesso a um elemento de matriz é quase o mesmo. Em alguns casos, é ainda mais rápido.
Não se trata de zipar dados, mas de os comprimir logicamente para formar matrizes indexadas. O tempo de acesso a um elemento de matriz é quase o mesmo. Em alguns casos ainda mais rápido.
Pronto para oferecer uma solução MQ?
Não estou inclinado a pensar que alguém que tenha feito algo como o MT seja um idiota. Nem sempre se justifica, mas muitas vezes é esse o caso. Por isso, há provavelmente algum fundo para a sua solução. Mas não é certo )
O que é a muleta?
Que um milhão de utilizadores estão protegidos (e os corretores juntamente com eles) e que é necessário recarregar o terminal 2 vezes?
A mim parece-me uma solução lógica. É muito mais lógico do que torná-lo conveniente apenas para si)
Qual é a defesa, Andrei?
Não é necessário reiniciar nada.
Os dados já se encontram nos ficheiros.
Pronto para oferecer uma solução MQ?
Não costumo pensar em alguém que tenha feito algo como MQ como um idiota. Nem sempre se justifica, mas muitas vezes é esse o caso. Por isso, há provavelmente algum fundo para a sua solução. Mas não é certo )
Vá lá.
Há sempre uma solução melhor para uma já existente.
Mas não se transforme num temporizador antigo.
Qual é a defesa, Andrei?
Não é necessário voltar a carregar nada.
Os dados já se encontram nos ficheiros.
A razão é que estes dados não serão lidos por indicadores e Consultores Especialistas, carregando a memória operacional. Para quê?
Vá lá.
Há sempre uma solução melhor do que a existente.
Mas não se torne um homem velho.
Tenho a certeza que pode.
Portanto, talvez não seja uma prioridade tão grande.
Na medida em que estes dados não serão lidos por indicadores e EAs, carregando também a RAM. Para que serve isso?
bem para se atirar no pé - há inúmeras opções como está.
Só por definir max_bars =Unlimited, o consumo de memória aumenta dramaticamente.
Aqui está um exemplo do terminal com max_bars = 5000
Agora mudar max_bars = Unlimited e recarregar o terminal.
Com as mesmas janelas abertas, o consumo de memória aumentou em mais de GB. No meu caso 11 vezes mais !!!!
Este é um normal ))
Pode verificá-lo você mesmo.
max_bars = Unlimited é um luxo muito duro.
Se
o meu pedido fosse concedido, nunca poderia usarmax_bars = Unlimited.
E para além de guardar memória na RAM, também reduziria grandemente esta pasta, que agora tenho cerca de 31GB. Penso cerca de 5 vezes isso. E seriam 6GB em vez de 30GB.
uma solução de muleta é manter a base de dados na mesma pasta, e nas pastas dos agentes para colocar links para a pasta com a base de dados
Sugeri há muito tempo que se implementasse em MT a possibilidade de escolher o caminho para pastas com fontes e bases de dados históricos.
Se vários terminais estiverem a aceder ao mesmo corretor, então usando as ligações pode-se obter um erro de acesso, mas isto não deve (teoricamente) ser um problema para os agentes.
Será mesmo?! Na ajuda do MT5 não encontrei nada sobre este separador de definições, quando é que ele apareceu? - Não faço a menor ideia.
Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais
Insectos, insectos, perguntas
Andrey Dik, 2021.05.30 19:58
Se quiser negociar no MetaTrader, tem de criar uma pasta de agente e copiar o link para a pasta com a base de dados para a mesma.
o mt propôs há muito tempo a implementação da capacidade de seleccionar o caminho para as pastas com fontes, bases de dados históricas.
Se vários terminais estiverem a aceder ao mesmo símbolo de corretor, poderá encontrar um erro de acesso utilizando as ligações, mas isto não deverá (teoricamente) ser um problema para os agentes.
bem para se atirar no pé - há inúmeras opções como está.
Só por definir max_bars =Unlimited, o consumo de memória aumenta dramaticamente.
Aqui está um exemplo do terminal com max_bars = 5000
Agora mudar max_bars = Unlimited e recarregar o terminal.
Com as mesmas janelas abertas, o consumo de memória aumentou em mais de GB. No meu caso 11 vezes maior !!!!
Este é um normal ))
Pode verificá-lo você mesmo.
max_bars = Unlimited é um luxo muito duro.
Se agora estamos a falar de consumo de memória,@fxsaber teve o mesmo problema há alguns meses atrás, mas com carraças de carregamento - depois de libertar matrizes com carraças, o terminal não liberta memória, mas armazena (durante 10 segundos?) estas carraças como uma cache
É altamente provável que o seu pedido tenha o mesmo problema - o consumo de memória não irá diminuir mas sim aumentar ( em espadas)
Isto é fornecido pelo terminal.
Sim, é verdade.
Obrigado pela resposta!
Seria muito conveniente ter um operador/função em MQL5 que verifica o cálculo de todos os indicadores e, se os indicadores forem calculados, o resultado é verdadeiro, caso contrário tem de ser feito com a sua própria função, verificando cada buffer de indicadores. Isto é muito relevante para uma EA que trabalha com indicadores TF multitarefa. E, esta característica do atraso do cálculo não permite utilizar correctamente o modo OHLC, porque no primeiro e segundo tick nem todos os indicadores são calculados, o que é crítico.