Optimisation des algorithmes. - page 5

 
Mathemat:
En principe, oui. Mais toujours pas plus de O(n).
Pas moins :) avec une bonne imagination on peut faire une dépendance exponentielle:)
 
Mathemat:

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 :

static void Up(Bars MyQuotes)
        {
            BitArray bits = new BitArray(MyQuotes.Count);
            double max = double.MinValue;
            int pperiod = (23 - 1) / 2;
            int bar = pperiod;
            int count = MyQuotes.Count - pperiod;
            //последняя позиция второго перебора.
            int pos = bar;
            while (bar < count)
            {
                for (int i = 1; i <= pperiod; i++)
                {
                    max = MyQuotes.High[bar - i] > MyQuotes.High[bar + i]
                              ? MyQuotes.High[bar - i]
                              : MyQuotes.High[bar + i];
                    pos = bar + i;
                    if(max > MyQuotes.High[bar])
                    {
                        //Начинаем с последнего бара
                        bar = pos;
                        break;
                    }
                    if(i == pperiod)
                    {
                        bits[bar + i] = true;
                        bar = pos;
                    }
                }
            }
        }

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.

 
C-4: J'ai donné les statistiques dans le premier message. Le calcul pour 1.000.000 de barres croît arithmétiquement à mesure que la période augmente. Ainsi, pour la période 3, le calcul prend 0,54 seconde, pour la période 51 0,94 seconde, et pour la période 99 il est déjà de 1,59 seconde.

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é.

 
Mathemat:

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.

Документация по MQL5: Доступ к таймсериям и индикаторам / Bars
Документация по MQL5: Доступ к таймсериям и индикаторам / Bars
  • www.mql5.com
Доступ к таймсериям и индикаторам / Bars - Документация по MQL5
 
Mathemat:

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é.

Si c'est quadratique, c'est encore pire. Sans le multithreading, tel que je le comprends, il n'y a aucun moyen de le contourner.
 

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.

 
Vous êtes en feu. Tous les trois.
 
hrenfx:

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.

En principe, j'ai besoin de ces extrêmes pour un zig-zag. Dans ce cas, quels sont les meilleurs algorithmes à utiliser ? Existe-t-il un code plus efficace que celui que j'ai cité dans la deuxième version ?
 
Découvrez les ZigZags à passage unique dans CodeBase MT4 - O(N).
 
TheXpert: Vous êtes en feu. Tous les trois.

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.