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
Em princípio, sim. Mas ainda não mais do que O(n).
Bem, isto não é um problema de optimização.
Encontrar um extremo é sempre um problema de ordem O(n), onde n é o número de dados. Como se pode tornar esta assimptótica pior - não faço ideia.
O algoritmo mais simples é o ArraySort(), que é incorporado suficientemente rápido, 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?
Dei as estatísticas no primeiro posto. O cálculo para 1.000.000 de barras aumenta aritmeticamente à medida que o período aumenta. Assim, para o período 3, o cálculo leva 0,54 segundos, para o período 51 leva 0,94 segundos, e para o período 99 leva 1,59 segundos.
Isto é pior porque utiliza o laço no laço, o que é um erro. Assim, para o período 3 o número de iterações será de 1 000 000 * (3-1/2) = 1 000 000, enquanto para o período 99 será de 1 000 000 * (99-1)/2 = 49 000 000! Por conseguinte, precisamos de reescrever o algoritmo de modo a que o número de iterações não aumente qualitativamente com o aumento do período - este é um puro problema de optimização. Isto é o que estou a fazer agora. Até agora, escrevi isto:
Para procurar o mínimo, a função correspondente Down() será lançada num fio paralelo. Quando ambas as funções terminam, os seus resultados serão escritos na lista geral. É algo parecido com isto.
Aí está, percebeu mal. Não é a soma de uma progressão rica, C-4. A soma cresce quadraticamente.
A OCL é inequívoca.
O algoritmo mais simples é o ArraySort(), incorporado suficientemente rápido, algo em torno de O(n * ln( n ) ), mas é provavelmente redundante para este problema.
Pensamento. Qualquer triagem será inerentemente mais lenta do que percorrer todo o conjunto. Pois dá uma iteração, enquanto que as arraysort na melhor das hipóteses ordenará os valores em cada subjanela n, o que por si só significará dezenas de acções.
Não, deve ainda visar que o número total de iterações seja qualitativamente o mesmo que o número de barras.
Aí está, percebeu mal. Não é a soma de uma progressão rica, C-4. A soma cresce quadraticamente.
A OCL é inequívoca.
A condição para uma busca tão extrema é, no mínimo, estranha. Mas mesmo assim, é extremamente irrazoável usar um método de busca por força bruta.
Um ZigZag clássico de uma passagem com ExtDepth = n vem imediatamente à mente com um ligeiro ajustamento à condição actual. O OCL é 100% desnecessário aqui.
A condição para uma busca tão extrema é, no mínimo, estranha. Mas mesmo assim, é extremamente irrazoável usar um método de busca por força bruta.
Um ZigZag clássico de uma passagem com ExtDepth = n vem imediatamente à mente com um ligeiro ajustamento à condição actual. O OCL é 100% desnecessário aqui.
Porquê? O(n) ainda lá estará, independentemente da forma como se olhe para ele.
Se tudo o resto falhar, tente OCL. Não há outras formas sem perversões do tipo dll em 5.