Características da linguagem mql5, subtilezas e técnicas - página 153
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
No ArrayReverse ajuda:
A funçãoArraySetAsSeries() não move fisicamente os elementos da matriz, mas apenas inverte a direcção de indexação para trás para organizar o acesso aos elementos como numasérie temporal. A função ArrayReverse() move fisicamente os itens da matriz para que a matriz seja "invertida".
Mas este código prova o oposto:
Porquê? É isso mesmo.
Se lidarmos com uma série em que a numeração é como numa série temporal, ou seja, a barra zero é a mais recente e a mais recente é a mais antiga, quando um novo elemento é adicionado, ele será próximo da mais recente, ou seja, a mais antiga.
E se a matriz não for numerada como nas séries temporais, então o elemento zero é o mais antigo e o mais recente é o mais recente. Por conseguinte, quando um novo elemento é adicionado, ele estará ao lado do mais recente.
Que é o que acontece no seu teste.
Onde está a prova aqui que eu não compreendo. Como o podemos provar e descobrir onde está o início da matriz na memória e que passo de incremento é positivo ou negativo.
Só o pode provar passando a matriz e usando apontadores.
Mas é mais fácil de o provar medindo o tempo que leva a executar esta operação. Se um conjunto de 100 000 000 de artigos "vira" instantaneamente, é evidente que não há viragem; a referência ao início muda e o incremento muda o seu sinal.
Eu uso a funçãoArraySetAsSeries() o tempo todo, e vejo que é absolutamente livre no tempo. Portanto, está enganado.
Para ser honesto, não entendo porque precisamos da funçãoArrayReverse lentaquando temos oArraySetAsSeries()
No ArrayReverse ajuda:
A funçãoArraySetAsSeries() não move fisicamente os elementos da matriz, mas apenas inverte a direcção de indexação para trás para organizar o acesso aos elementos como numasérie temporal. A função ArrayReverse() move fisicamente os itens da matriz para que a matriz seja "invertida".
Mas este código prova o oposto:
Tem uma reatribuição de memória para uma matriz com a bandeira asSeries, naturalmente que levaram isso em conta. Devem ter aí algo parecido com isto:
Tem uma realocação de memória para uma matriz com a bandeira asSeries, claro que tiveram isso em conta. Devem ter aí algo do género:
Sim, eles devem tê-lo tido em conta. Mas este comportamento não corresponde aCopyRates():
Independentemente da propriedade da matriz receptora - as_series=verdadeiro ou as_series=falso, os dados serão copiados para que o elemento mais antigo no tempo esteja no início da memória física atribuída à matriz.
Também paraArrayCopy():
Se contar<0 ou contar>src_size-src_start, todo o resto da matriz é copiado. As arrays são copiadas da esquerda para a direita. Para matrizes em série, a posição inicial é anulada correctamente , tendo em conta a cópia da esquerda para a direita.
Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.
Não sei como o fazem, na realidade é uma língua de intérprete.
Pergunto-me se será o mesmo com Python.
É claro que não está a dizer que a MQL5 é má. É que Java é demasiado fixe.
Deve-me ter escapado alguma coisa. Desde quando é que os intérpretes se tornaram tão rápidos como os compiladores?
Aparentemente, isto só é possível com uma compilação parcial, ou seja, os intérpretes não são puros.
Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.
Não sei como o fazem, na realidade é uma língua de intérprete.
Pergunto-me se será o mesmo com Python.
É claro que não está a dizer que a MQL5 é má. É que Java é demasiado fixe.
Deve-me ter escapado alguma coisa. Desde quando é que os intérpretes se tornaram tão rápidos como os compiladores?
Aparentemente, isto só é possível com uma compilação parcial, ou seja, os intérpretes não são puros.
A MQL é também uma intérprete.
Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.
Não compreendo como o conseguem fazer, na realidade é uma língua de intérprete.
Pergunto-me se será o mesmo com Python.
É claro que não está a dizer que a MQL5 é má. É que Java é demasiado fixe.
Deve-me ter escapado alguma coisa. Desde quando é que os intérpretes se tornaram tão rápidos como os compiladores?
Aparentemente, isto só é possível com uma compilação parcial, ou seja, os intérpretes não são puros.
Java, embora traduzida em bytecode, tem a sua própria máquina de execução virtual (JVM).
A língua é também estritamente dactilografada, ao contrário de outras línguas com um intérprete.
Muito provavelmente, a digitação rigorosa e a JVM são a razão para a rápida execução e transmissão de instruções para o hardware.
Os terminais comerciais americanos são escritos em Java por uma razão. O Grupo CME em Chicago oferece oficialmente terminais escritos em Java.
Um programador disse-me uma vez que Java tem as suas raízes nas telecomunicações.
Nas telecomunicações é preciso ter a velocidade de processamento e transferência de dados.
E a Oracle tem a sua própria comunidade para o desenvolvimento desta língua.
Ou seja, a língua está viva e a ser finalizada pela comunidade Oracle.
A propósito, a marca Quik e a língua LUA também foram desenvolvidas pelos americanos.
Mas na década de 90, foi vendida com sucesso à Federação Russa.
Naqueles anos, os americanos já compreendiam que a LUA não tinha qualquer desenvolvimento futuro.
E despejaram-na com sucesso na Federação Russa, onde uma bolsa de valores tinha acabado de começar a formar-se após o colapso da União.
Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.
Não compreendo como o fazem, é essencialmente uma língua de intérprete.
O modelo lá é o mesmo que em .Net - o código fonte é compilado em bytecode, será um intérprete, e quando se desempacota o bytecode num determinado PC, o código nativo será gerado para o ambiente virtual onde será executado, ou seja, será compilado código
https://habr.com/ru/post/107585/
google "compilador ou intérprete de Java" para Java - haverá artigos semelhantes
A MQL é também uma intérprete.
Justificação?
Estou um pouco em estado de choque. Escrevi um teste em Java. Acontece que Java é quase tão rápido como C, e portanto ligeiramente mais rápido do que MQL5.
Não sei como o fazem, na realidade é uma língua de intérprete.
Pergunto-me se será o mesmo com Python.
É claro que não está a dizer que a MQL5 é má. É que Java é demasiado fixe.
Deve-me ter escapado alguma coisa. Desde quando é que os intérpretes se tornaram tão rápidos como os compiladores?
Aparentemente, isto só é possível com uma compilação parcial, ou seja, os intérpretes não são puros.
Alguma vez se perguntou quanto tempo de arranque leva? Quanta memória é devorada e quantos fios a JVM corre para compilar bytes de código? Corri monstro que compilou o mundo do olá na mosca e acabou com ambos nativ. Excepto que o monstro C não tem um. E sobre python.
Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos
MetaTrader 5 Python User Group - Como usar Python em Metatrader
Vitória, 2019.12.07 07:12
Sobre python - recentemente falou-se sobre ranger (gestor de ficheiros), que está escrito no mesmo. Utilizei-a durante alguns dias e a minha impressão é que é uma ideia fixe com características interessantes, mas a pitão é realmente lenta (se algumas tarefas complicadas forem executadas em segundo plano). Arrancado, não sei porque é que as pessoas são tão atraídas pela pitão. Colocar uma coisa semelhante em C.Bem ok - compre um triturador de números multi-core com uma carroça de RAM e diga o meu java/sharp/... são muito fixes neste teste, e vamos manter-nos calados sobre a carga global. Eles nunca alcançarão C. Progresso, tomar tetris dos anos 80, reescrevê-lo em sharpe, e correr tão rápido como antes, mas com um CPU de 60 núcleos)).
ZS: semelhante a como dois fios em Elbrus só estão envolvidos na transmissão a partir de instruções x86. BelAZ a transportar uma encomenda.