Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
En principe, oui. Mais toujours pas plus de O(n).
Ce n'est pas un problème d'optimisation.
La recherche d'un extremum est toujours un problème d'ordre O(n), où n est le nombre de données. Je n'ai aucune idée de la façon dont on peut aggraver cette asymptotique.
L'algorithme le plus simple est ArraySort(), qui est intégré assez rapidement, mais il est probablement redondant pour ce problème.
Vous pourriez trouver quelque chose de récursif qui serait plus rapide.
Combien de temps faut-il pour trouver le minimum et pour combien de barres ?
J'ai donné les statistiques dans le premier message. Le calcul pour 1.000.000 de barres augmente arithmétiquement au fur et à mesure que la période augmente. Ainsi, pour la période 3, le calcul prend 0,54 seconde, pour la période 51, il prend 0,94 seconde, et pour la période 99, il prend 1,59 seconde.
C'est pire car il utilise la boucle dans la boucle, ce qui est une erreur. Ainsi, pour la période 3, le nombre d'itérations sera de 1 000 000 * (3-1/2) = 1 000 000, tandis que pour la période 99, il sera de 1 000 000 * (99-1)/2 = 49 000 000 ! Nous devons donc réécrire l'algorithme de manière à ce que le nombre d'itérations n'augmente pas qualitativement avec l'augmentation de la période - il s'agit d'un pur problème d'optimisation. C'est ce que je fais maintenant. Jusqu'à présent, j'ai écrit ceci :
Pour rechercher le minimum, je vais utiliser la fonction correspondante Down() qui s'exécute dans le fil parallèle. Lorsque les deux fonctions se terminent, leurs résultats seront écrits dans la liste générale. Ça donne quelque chose comme ça.
Et voilà, vous vous êtes trompé. Ce n'est pas la somme d'une progression riche, C-4. La somme croît de façon quadratique.
OCL est sans ambiguïté.
L'algorithme le plus simple est ArraySort(), intégré assez rapidement, quelque chose autour de O(n * ln( n ) ). Mais il est probablement redondant pour ce problème.
Pensée. Tout tri sera intrinsèquement plus lent que de parcourir l'ensemble du tableau via for. Pour donner une itération, alors que arraysort au mieux triera les valeurs dans chaque sous-fenêtre n, ce qui en soi signifiera des dizaines d'actions.
Non, vous devez toujours chercher à ce que le nombre total d'itérations soit qualitativement le même que le nombre de barres.
Et voilà, vous vous êtes trompé. Ce n'est pas la somme d'une progression riche, C-4. La somme croît de façon quadratique.
OCL est sans ambiguïté.
La condition pour une telle recherche d'extrémum est pour le moins étrange... Mais même ainsi, il est extrêmement déraisonnable d'utiliser une méthode de recherche par force brute.
Le classique ZigZag en un seul passage avec ExtDepth = n vient immédiatement à l'esprit avec une légère adaptation à la condition actuelle. L'OCL est 100% inutile ici.
La condition pour une telle recherche d'extrémum est pour le moins étrange... Mais même ainsi, il est extrêmement déraisonnable d'utiliser une méthode de recherche par force brute.
Un ZigZag classique en un seul passage avec ExtDepth = n vient immédiatement à l'esprit avec un léger ajustement à la condition actuelle. L'OCL est 100% inutile ici.
Pourquoi ? O(n) sera toujours là, quelle que soit la façon dont vous le regardez.
Si tout le reste échoue, essayez OCL. Il n'y a pas d'autres moyens sans perversions de type dll en 5.