Implementações alternativas de funções/abordagens padrão - página 13
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
Este é o aspecto do início do bloco:
Tanto quanto eu o entendo, você criou sua própria língua de intérprete.
Assim?
Outra pergunta boba:
cada janela gerada com diferentes elementos é um recurso ou muitos?
Embora, uma melhor analogia seria provavelmente o HTML
Como eu disse antes, seu filho precisa de um construtor gráfico. Algo como Andrei Barinov's.
Também seus videoclipes são muito longos. Você precisa reduzi-los de 45 minutos para 5 minutos, ou melhor ainda - 3 minutos.
Você mesmo já tentou encontrar a resposta para a pergunta?
Dica: Na busca no google, digite "DBL_MANT_DIG 53 52".
Sim, obrigado. Encontrei-a.
1. Tanto quanto eu o entendo, você criou sua própria língua de intérprete.
Assim?
E uma pergunta boba:
cada janela gerada com diferentes elementos é um recurso ou muitos?
Embora, talvez uma melhor analogia fosse a linguagem HTML.
Como eu disse antes - sua criação precisa de um construtor gráfico. Algo como Andrei Barinov's.
Também seus videoclipes são muito longos. De 45 minutos eles devem ser reduzidos para 5 minutos, ou melhor ainda, para 3.
1. Sim, acontece que a definição de "intérprete" se adapta melhor ao que eu criei (embora no processo de criação eu não tivesse a menor idéia do que é).
2. Cada janela formada consiste de vários Kanvases (recursos). As duas primeiras são plataformas de janelas. Antes eu estava usando um método de desenho diferente e, portanto, algumas peças eram semi-transparentes e era possível ver o gráfico através delas. Para evitar que eu tenha acrescentado outro kanvas em segundo plano. Então a técnica melhorou, mas a tela fica em segundo plano. Cresceu para a tecnologia e é difícil se livrar dela agora. Mas eventualmente eu a removerei e a plataforma da janela consistirá em uma tela.
Além disso, os "campos (abas de imagem comutáveis), são telas independentes. Elas contêm imagens prontas e, portanto, mudam o mais rápido possível. Se eu desenhasse tudo em uma única tela, inevitavelmente a troca de imagem seria mais lenta. De qualquer forma, depois de pensar sobre isso, cheguei à conclusão de que esta é a melhor opção.
3. Visual Constructor era, e ainda é, meu objetivo. Estou muito próximo do início de sua implementação. Há uma compreensão de sua estrutura. Há todos os conceitos necessários para sua implementação. Eu sei como fazer isso. Tudo o que preciso é de tempo.
ZS. A peculiaridade do meu desenvolvimento é a espontaneidade. Eu não estava familiarizado com interpertadores ou linguagem HTML, e não sabia como eles funcionam. Entretanto, isso não me impede de criar e fazer coisas semelhantes. Acho que se funcionar bem, continuarei fazendo isso. :)
À primeira vista, você parece ter um uso muito esbanjador de memória. Posso estar errado, no entanto.
Idealmente, sua tarefa deveria ter apenas uma tela que apóie a transparência sobre a tabela de preços.
O desempenho da MQL5 deve ser suficiente para formar toda a interface em tempo real sem ter blocos prontos na memória, se a codificação estiver correta.
Embora eu não exclua a possibilidade de sacrificar recursos de memória para aumentar o desempenho de interfaces incômodas.
Vejo uma grande vantagem em sua abordagem até agora:
Será mais fácil para você criar um construtor gráfico completo, pois é mais fácil gerar código de marcação do que o próprio código MQL.
Mas é uma tarefa elefantina.À primeira vista, você parece ter um uso muito esbanjador de memória. Posso estar errado, no entanto.
Idealmente, sua tarefa deveria ter apenas uma tela que apóie a transparência sobre a tabela de preços.
O desempenho da MQL5 deve ser suficiente para formar toda a interface em tempo real sem ter blocos prontos na memória.
Embora eu não exclua a possibilidade de sacrificar recursos de memória para aumentar o desempenho de interfaces incômodas.
Vejo uma grande vantagem em sua abordagem até agora:
Será mais fácil para você criar um construtor gráfico completo, pois é mais fácil gerar código de marcação, não o código MQL em si.
Mas é uma tarefa elefantina.Ainda há uma quantidade relativamente pequena de memória excedida. Você está certo. Objetos de elementos como texto ou ícone são "imerecidamente", dado um número de 235 propriedades no núcleo, enquanto suas próprias propriedades são várias vezes menores. O objeto elemento principal, ou seja, a base, deve ter todas as 235 propriedades, mas os objetos de ícone e texto têm menos propriedades. Isto cria uma sobrecarga de memória.
A idéia é que se eu adicionar mais 60 células à linha de objetos principais, posso colocar texto e propriedades de ícones neles. Isto tornaria o núcleo "mais amplo", mas você poderia remover dois terços dos objetos.
Haveria uma excelente economia de memória e um ganho na velocidade de construção do kernel. No entanto, isto é tecnicamente difícil de implementar. Há muito retrabalho a ser feito. Até agora, o consumo de memória e o tempo de construção são bastante aceitáveis. Mas não há limite para a perfeição...
Usar uma lona não é uma boa idéia. É muito mais fácil usar uma tela para cada janela e uma tela para cada campo. A tela genérica precisa ser redesenhada com muito mais freqüência. Para cada troca de imagem ou cada mudança de janela. Na rolagem... Deve-se levar em conta que o redesenho nem sempre é rápido. Não está nos algoritmos, mas na "sofisticação" dos gráficos. Deixe-me explicar:
Se você desenhar uma simples etiqueta retangular (um quadrado, por exemplo), é um ciclo sobre um conjunto de pixels com as células certas inicializadas com o valor correto (cor).
Se você desenha um quadrado com uma moldura, são dois ciclos em uma matriz de pixels.
Se você desenha um quadrado com uma moldura e um ícone, são três ciclos.
Se você desenhar um quadrado com uma moldura que tenha um gradiente de superfície e um ícone que tenha uma sombra, são quatro ou mais ciclos na matriz de pixels.
Portanto, quanto mais inclinado o gráfico, mais você precisa "engomar" esta matriz de pixels em ciclos, criando a imagem correta. Portanto, quanto menos a necessidade de redesenhar, melhor.
Uma tela para todas as imagens, fará com que você redesenha tudo continuamente. Portanto, não é uma boa solução.
ZS. A tarefa é certamente elefantina, mas eu posso fazer isso. (Embora eu receba ajuda)).
ZS. Obrigado pelo vídeo, é inspirador! :)
Você redimensiona a janela com o mouse?
Em caso afirmativo, aparece um quadrado vermelho?
Você redimensiona a janela com o mouse?
Em caso afirmativo, aparece um quadrado vermelho?
Eu não entendo de que quadrículas estamos falando.
A janela dinâmica pode ser redimensionada com o mouse. De que outra forma poderia ser?
ZS: A janela dinâmica tem inicialmente um tamanho de tela cheia. Além disso, é "aparado" até o tamanho exigido. Em outras palavras, todo o seu dinamismo é realizado no tamanho máximo do bitmap já criado.
Para continuar o tópico de arredondamento.
Descobri que os modernos processadores Intel que suportam o conjunto de instruções SSE4.1 estendido têm comando de arredondamentoROUND{PS, PD} . Tenho certeza de que a AMD tem algo semelhante.
https://ru.wikipedia.org/wiki/SSE4#SSE4a
http://o-ili-v.ru/wiki/SSE4
Isto significa que o compilador MQL5 não usa este comando a nível de CPU? Uma vez que meu processador Intel Kaby Lake suporta este conjunto.
E há muito mais, até mesmo a multiplicação escalar dos vetores.