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
Agora tenho um problema. Preciso de fazer uma classificação eficiente de matrizes com grandes "custos" de cópia de elementos (ou seja, elementos dos quais são grandes, estruturas "pesadas", objectos de classe, cordas longas, etc.). O senso comum sugere que devemos deixá-los no lugar, mas ordenar em vez disso algum tipo de ponteiros - índices de células da sua localização original. Aqui está a citação de https://www.mql5.com/ru/forum/6476#comment_178318Оставим até agora, e vamos implementá-la no mql5.
Tudo já foi roubado antes de nós :)
Folhas de cálculo em MQL5
A entrada deve ser uma cópia da matriz a ser classificada, os comentários devem ser anotados, e os desnecessários devem ser comentados
Tudo já foi roubado antes de nós :)
Folhas de cálculo em MQL5
A entrada deve ser uma cópia da matriz a ser classificada, os comentários devem ser anotados e os comentários desnecessários devem ser comentados.
Estragaste a canção... Ou melhor - tentou fazê-lo. :)
// É evidente que existem boas aproximações. Poderia muito bem ter tirado uma amostra da biblioteca padrão. :)
Existem padrões. E também há alguns excelentes. Mas ainda assim. Aqui é importante especificar e depurar tudo para uma condição de trabalho de um produto utilizável separado. Além disso (porque o estou a enviar para aqui) - o mais rápido possível. Isto é, sugiro que se aperte todo o desempenho possível até centésimos de um por cento inclusive. :)
Este é o primeiro. Em segundo lugar, para objectos precisamos do número de matrizes indexadas igual ao número de critérios de ordenação, que em geral podem ser vários, + (de preferência) função de inserção em ordenação de acordo com vários critérios indexados.
Estragaste a canção... Ou melhor, tentou. :)
// É evidente que existem boas aproximações. Poderia muito bem ter tirado uma amostra da biblioteca padrão. :)
Há amostras. E mesmo alguns grandes. Mas ainda assim. É importante verificar e depurar tudo até à condição de funcionamento de um produto utilizável separado. E (porque o estou a enviar para aqui) - o mais rápido. Isto é, sugiro que se aperte todo o desempenho possível até centésimos de um por cento inclusive. :)
Isso é a primeira coisa. Segundo - para objectos precisamos do número de matrizes indexadas igual ao número de critérios de ordenação, que em geral podem ser vários, + (de preferência) função de inserção em ordenação por vários critérios de matriz indexada.
A mesma resposta Folhas de cálculo em MQL5.
Está tudo aí. Sob um problema concreto, é possível refazer sob manipulação não de colunas mas de filas, há colunas feitas para que seja possível declará-las como diferentes tipos. Se o tipo de mesa for o mesmo, tudo pode ser reproduzido.
Feito um inluder com índices de ordenação para tipos de base.
A classificação por defeito é "decrescente", para classificar em direcção ascendente, definir a bandeira de classificação em direcção falsa.
Resultados dos testes: // matrizes de indexação duplo[], int[], string[]; sequencialmente: matriz bruta, matriz descendente, matriz ascendente
Biblioteca e teste em reboque.
Colocar o indexador na pasta "MQL5Inclua os índices".
Aqui está uma aula de amostra para trabalhar com OCL. É claro que algumas coisas são incompletas e incómodas, mas talvez alguém o considere útil.
Refiz um pouco a inicialização, agora é possível fazer cálculos multidimensionais.
Grande tema!
Ainda agora enfrentei um problema de optimização com um algoritmo para encontrar um preço extremo (mínimo). As condições são as seguintes: há uma barra, n barras à esquerda e à direita das quais estão abaixo (acima) do seu máximo:
n é um valor escolhido arbitrariamente e gratuito. O período n é sempre estranho, porque a soma das duas barras à direita e à esquerda será sempre um número par ao qual se acrescenta a barra central do preço extremo propriamente dito.
Não pensei muito sobre a primeira versão do algoritmo e escrevi o código mais óbvio. Agora estou a escrevê-lo em C# usando a plataforma WealthLab, mas penso que se pode facilmente compreender a essência do algoritmo problemático, aqui está a parte mais problemática do mesmo:
Todo o problema está na segunda etapa. Lida simultaneamente com ramos esquerdos e direitos de um potencial extremo e, portanto, passa apenas por (N - 1)/2 barras, mas isso não é suficiente. As medições mostram que o tempo gasto na identificação de um extremo numa progressão aritmética depende do período N, que é muito, muito mau:
Tentar através dos períodos levará o tempo necessário para resumir a progressão aritmética, e este é um valor muito grande.
Uma solução possível é a introdução de uma variável adicional. Afinal, se um extremo for identificado, é garantido que não há barra à sua direita para (N - 1)/2 de modo a que um novo extremo possa ser identificado começando com barra: actual_bar + (N - 1)/2. No entanto, os extremos têm de ser identificados juntamente com os mínimos e um novo mínimo pode ser encontrado antes do actual_bar + (N - 1)/2. Será portanto necessário dividir a procura de extremos e mínimos em duas passagens que negarão qualquer ganho de desempenho. Podemos facilmente dividir duas passagens em dois fios processados simultaneamente em dois núcleos em C#, mas gostaria de encontrar o algoritmo óptimo e optimizá-lo antes de mais nada. Estou à espera da ajuda de peritos.
Bem, isto não é um problema de optimização.
Tentar através dos períodos levará a soma da progressão aritmética, e este é um valor muito grande.
Encontrar um extremo parece ser um problema da ordem de O(n), onde n é o número de dados. Como se pode piorar esta assimptótica, ou seja, O(n^2) - Nem consigo imaginar. Ou está a confundir os termos.
O algoritmo mais simples é o ArraySort(), incorporado suficientemente rápido, algo em torno de O(n * ln( n ) ), mas é provavelmente redundante para este problema.
Poderia surgir algo recursivo que fosse mais rápido.
Quanto tempo demora a encontrar o mínimo e por quantos bares? Bem, não acredito que durante 100 barras esteja à procura de um máximo de um segundo e meio.
O algoritmo mais simples é o ArraySort(), a classificação integrada é suficientemente rápida, mas é provavelmente redundante para esta tarefa.
A melhor ordenação é O(n*log(n)). Exactamente redundante.
Poderíamos encontrar algo recursivo que seria mais rápido.
Mais devagar. A recorrência é mais frequentemente maligna. Recursivo? Este é provavelmente um caso em que não importa como o faça, a velocidade será praticamente a mesma.
Por código:
Ciclos para min e max devem ser explicitamente separados. E sair imediatamente do laço se este falhar.
Em princípio, sim. Mas ainda não mais do que O(n).
A OCL ajudaria aqui. As assimptóticas permanecerão as mesmas, é claro. Mas a velocidade poderia muito bem ser aumentada em cem vezes.