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
Maintenant, j'ai un problème. J'ai besoin de faire un tri efficace des tableaux avec un grand "coût" de la copie des éléments (c'est-à-dire les éléments dont les structures sont grandes, "lourdes", des objets de classe, de longues chaînes, etc). Le bon sens suggère que nous devrions les laisser en place, mais trier à la place une sorte de pointeurs - index des cellules de leur emplacement d'origine. Voici la citation de https://www.mql5.com/ru/forum/6476#comment_178318Оставим jusqu'à présent, avec leurs nombreuses tâches en cours, et l'implémenter dans mql5.
Tout a déjà été volé avant nous :)
Feuilles de calcul dans MQL5
L'entrée doit être une copie du tableau à trier, les commentaires doivent être annotés, et le superflu doit être commenté.
Tout a déjà été volé avant nous :)
Feuilles de calcul dans MQL5
L'entrée doit être une copie du tableau à trier, les commentaires doivent être annotés et le superflu commenté.
Tu es méchant ! Tu as gâché la chanson... Ou plutôt, j'ai essayé. :)
// Il est clair qu'il existe de bonnes approximations. J'aurais pu aussi bien tirer un échantillon de la bibliothèque standard. :)
Il y a des modèles. Et il y en a d'excellentes, aussi. Mais quand même. Dans ce cas, il est important de tout enregistrer et de tout déboguer pour obtenir un produit utilisable distinct. De plus (pourquoi je l'envoie ici) - le plus vite possible. C'est-à-dire que je suggère d'exploiter toutes les performances possibles jusqu'aux centièmes de pour cent inclus. :)
C'est le premier. Deuxièmement, pour les objets, nous avons besoin d'un nombre de tableaux d'index égal au nombre de critères de tri, qui, dans le cas général, peuvent être plusieurs, + (de préférence) une fonction d'insertion dans un tableau indexé trié selon plusieurs critères.
Tu es méchant ! Tu as gâché la chanson... Ou plutôt, vous avez essayé. :)
// Il est clair qu'il existe de bonnes approximations. J'aurais pu aussi bien tirer un échantillon de la bibliothèque standard. :)
Il y a des échantillons. Et même quelques grands. Mais quand même. Il est important de tout vérifier et de tout déboguer pour obtenir un produit distinct et utilisable. Et (pourquoi je l'envoie ici) - le plus rapide. C'est-à-dire que je suggère d'exploiter toutes les performances possibles jusqu'aux centièmes de pour cent inclus. :)
C'est la première chose. Deuxièmement - pour les objets, nous avons besoin d'un nombre de tableaux d'index égal au nombre de critères de tri, qui en général peuvent être plusieurs, + (de préférence) une fonction d'insertion dans un tableau indexé trié par plusieurs critères.
Même réponse Feuilles de calcul dans MQL5.
Tout est là. Sous un problème concret, il est possible de refaire sous manipulation non pas des colonnes mais des lignes, il y a des colonnes faites pour il est possible de les déclarer comme des types différents. Si le type de table est le même, tout peut être rejoué.
Réalisation d'un inluder avec des index de tri pour les types de base.
Le tri par défaut est "descendant", pour trier dans la direction ascendante, mettez l'indicateur de direction du tri à false.
Résultats du test : // indexation des tableaux double[], int[], string[] ; séquentiellement : tableau brut, tableau descendant, tableau ascendant
Bibliothèque et test dans la remorque.
Placez l'indexeur dans le dossier "MQL5\Include\Indexes\".
Voici un exemple de classe pour travailler avec OCL. Bien sûr, certaines choses sont incomplètes et maladroites, mais peut-être que quelqu'un trouvera cela utile.
J'ai retravaillé un peu l'initialisation, maintenant vous pouvez exécuter des calculs multidimensionnels.
Grand sujet !
Je viens d'être confronté à un problème d'optimisation avec un algorithme pour trouver un extremum (minimum) de prix. Les conditions sont les suivantes : il existe une barre, dont n barres à gauche et à droite sont inférieures (supérieures) à son maximum :
n est une valeur libre choisie arbitrairement. La période n est toujours impaire, car la somme des deux barres à droite et à gauche sera toujours un nombre pair auquel on ajoute la barre centrale de l'extremum de prix proprement dit.
Je n'ai pas beaucoup réfléchi à la première version de l'algorithme et j'ai écrit le code le plus évident. Maintenant, je l'écris en C# en utilisant la plateforme WealthLab, mais je pense que vous pouvez facilement comprendre l'essence de l'algorithme problématique, voici la partie la plus problématique de celui-ci :
Tout le problème est dans la deuxième boucle. Il traite simultanément les branches gauche et droite d'un extremum potentiel et ne passe donc que par (N - 1)/2 barres, mais cela ne suffit pas. Des mesures montrent que le temps passé à identifier un extremum dans une progression arithmétique dépend de la période N, ce qui est très, très mauvais :
En parcourant les périodes, il faudra du temps pour résumer la progression arithmétique, et il s'agit d'une très grande valeur.
Une solution possible est d'introduire une variable supplémentaire. Après tout, si un extremum est identifié, il est garanti qu'il n'y a pas de barre à sa droite pendant (N - 1)/2, de sorte qu'un nouvel extremum peut être identifié en commençant par bar : current_bar + (N - 1)/2. Cependant, les extrema doivent être identifiés en même temps que les minima et un nouveau minimum peut être trouvé avant current_bar + (N - 1)/2. Il sera donc nécessaire de diviser la recherche des extrema et des minima en deux passes, ce qui annulera tout gain de performance. Nous pouvons facilement diviser deux passes en deux threads traités simultanément sur deux cœurs en C# mais j'aimerais d'abord trouver l'algorithme optimal et l'optimiser. J'attends l'aide d'experts.
Ce n'est pas un problème d'optimisation.
En essayant de parcourir les périodes, on obtient la somme de la progression arithmétique, et cette valeur est très grande.
La recherche d'un extremum semble être un problème de l'ordre de O(n), où n est le nombre de données. Comment vous pouvez rendre cette asymptotique pire, c'est-à-dire O(n^2) - je ne peux même pas imaginer. Ou vous confondez les termes.
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.
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 ? Eh bien, je ne crois pas que vous cherchiez un maximum d'une seconde et demie pour 100 barres.
L'algorithme le plus simple est ArraySort(), le tri intégré est assez rapide, mais il est probablement redondant pour cette tâche.
Le meilleur tri est O(n*log(n)). Exactement redondant.
On pourrait trouver quelque chose de récursif qui serait plus rapide.
Plus lentement. La récursion est le plus souvent maléfique. Récursif ? Il s'agit probablement d'un cas où, quelle que soit la façon dont vous le faites, la vitesse sera à peu près la même.
Par code :
Les cycles pour min et max doivent être explicitement séparés. Et quittez la boucle immédiatement si elle échoue.
En principe, oui. Mais toujours pas plus de O(n).
OCL serait utile ici. L'asymptotique restera la même, bien sûr. Mais la vitesse pourrait bien être multipliée par cent.