Tâche de traçage (construction d'un graphique de fonction) - page 2
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
Une seule et même fonction peut être appelée à la fois à partir de start et de init. Cela devrait être corrigé.
Je peux le faire sur mes doigts, mais il faut y réfléchir...)
comme ça :
comptez le nombre de fonctions, disons 4, écrivez #define X 4 dans l'en-tête du code
supposez que le nombre maximum d'appels sur un tick est #define Y 100
nous avons une matrice de taille 4 x 100, initialiser matrice = -1
et maintenant, lors de l'appel d'une fonction au point d'entrée de la fonction, ajouter un appel du compteur (façonneur de graphique), qui devrait ajouter le code (1,2,3 ou 4) à la position désirée X à l'entrée dans notre matrice sur la ligne libre - qui a appelé
Je pense que votre problème ressemble plus à des graphes de réseau, je soupçonne que la matrice pour les graphes de réseau a été développée depuis longtemps - vous devez googler
SZY : eh bien, voici déjà la 2ème page du sujet ;)
IgorM, la façon dont vous proposez de stocker le graphe est appelée "matrice d'adjacence". C'est très peu rentable pour les graphes épars (et les programmeurs devraient être battus pour l'architecture "graphes connectés complets", etc.)
Il est préférable d'utiliser une liste de bords (c'est-à-dire que nous stockons un tableau unidimensionnel de structures composées de 2 éléments - id de la fonction appelante et id de la fonction appelée ; la structure peut être complétée par des champs supplémentaires - compteurs d'appels, etc.)
p.s. Le matapparatus a vraiment été développé il y a longtemps :)
IgorM, la façon dont vous proposez de stocker le graphe s'appelle une "matrice d'adjacence".
Preuve de l'impossibilité d'une idée ?
. Il existe des destructeurs et le déroulement de la pile.
Bien que... pour le même C++, il existe des bibliothèques qui vous permettent de construire l'ordre des appels de fonctions pour n'importe quel
point du code par pile.
.
Donc... chaque retour signifie des appels supplémentaires :-).
Un arbre est un cas particulier de graphe.
Oui, c'est ce que je voulais dire. Sur la base de la linéarité du code MQL - il s'agira d'un arbre dans sa forme pure. Puisque les nœuds ne pointeront pas les uns vers les autres.
IgorM:
avoir une matrice de dimension 4 x 100, initialiser la matrice = -1
et maintenant quand nous appelons la fonction au point d'entrée de la fonction, nous ajoutons un appel du compteur (graph shaper) qui devrait ajouter un code (1,2,3 ou 4) à la position requise X à la ligne libre à l'entrée dans notre matrice - qui l'a appelé
Oui, je le vois maintenant. Mais il me semble que cette approche demande beaucoup de travail, non pas tant en termes de code que de ressources et de préparation à l'analyse. Pour la ramification, il faudrait faire une matrice tridimensionnelle.
En général, l'option est acceptée. Mais laissons cela à la page 4 du résumé pour l'instant :)
Je pense que votre problème ressemble plus à des graphes de réseau, je soupçonne que l'appareil mathématique pour les graphes de réseau a été développé depuis longtemps - vous devez googler
La tâche n'est ni un savoir-faire, ni une nouveauté. Juste un simple graphique de fonctions. Rien de plus.
Il n'y a pas de nouvelles mathématiques, nous avons juste besoin d'une version simplifiée autant que possible.
Il vaut mieux utiliser une liste de bord (c'est-à-dire stocker un tableau unidimensionnel de structures composées de 2 éléments - id de la fonction appelante et id de la fonction appelée ; la structure peut être complétée par des champs supplémentaires - compteurs d'appels, etc.)
Eugène, c'est exactement ce qui a déjà été fait.
Mais le code est au point mort. Pour le troisième jour, je ne peux ni dormir ni boire.... . :)
Je n'arrive pas à comprendre comment faire un retour de l'arête (plus précisément du nœud descendant) vers le nœud parent pour aller vers la nouvelle arête (nouveau nœud descendant). Mais pour respecter la règle, nous n'utilisons qu'une seule fonction de traçage au début de la fonction source.
Je n'arrive pas à trouver comment faire un retour d'une côte vers un nœud pour aller vers une nouvelle branche.
Et tout cela avec une seule fonction qui a déjà fait une passe en avant ? Vous en avez assez fait - faites un retour sans rien faire du tout))). Eh bien, rien, c'est la deuxième page qui est déjà terminée, bientôt Vladimir ne pourra plus la supporter)))).
Que Dieu soit avec eux, avec ces pages. La tâche est intéressante.
Vous voyez, c'est ainsi que vous pouvez.... Le retour au nœud parent peut déjà être effectué dans le nouveau descendant appelé. En d'autres termes, lorsque vous accédez au descendant, le système descend d'abord dans l'arbre jusqu'à un niveau inférieur, puis remonte jusqu'au nouveau descendant appelé.
Mais dans cette option on ne peut pas faire des branches avec une profondeur de plus de deux. Parce que le système reviendra toujours en arrière avant d'aller de l'avant. C'est-à-dire que toutes les fonctions seront dessinées au même niveau.
Il semble donc que nous devrons utiliser des tableaux de variables, pour identifier la position actuelle. pour aller plus loin et ne pas revenir. C'est exactement la complexité de ce retour...
Dans la remorque "pièce conceptuelle", plus précisément un exemple de mise en œuvre. sur MT 5
Les fonctions In() et out() doivent être réécrites pour les faire fonctionner avec la liste d'appels. Maintenant, ils impriment simplement les entrées et les sorties dans le fil standard.
Mauvaise nouvelle : je n'ai pas sauvegardé le rêve du topicstarter d'une fonction de traçage. Désolé Sergeyev. :)
Bonne nouvelle : tout fonctionne.
Manuel de l'utilisateur.
1. La macro "_in" est insérée au début de chaque fonction.
2. Tous les appels de retour sont remplacés par "_return".
3. Deux définitions sont écrites au début du programme
#define _in in(__FUNCTION__) ;
#define _return out(__FUNCTION__) ; retour
C'est tout.
C'est quoi ce bordel avec ces pages. C'est une tâche intéressante.
Vous voyez, c'est ainsi que vous pouvez.... Le retour au nœud parent peut déjà être effectué dans le nouveau descendant appelé. En d'autres termes, lorsque vous accédez au descendant, le système descend d'abord dans l'arbre jusqu'à un niveau inférieur, puis remonte jusqu'au nouveau descendant appelé.
Mais dans cette variante, vous ne pouvez pas faire des branches avec plus de deux profondeurs. Parce que le système revient toujours en arrière avant d'avancer. C'est-à-dire que toutes les fonctions seront dessinées au même niveau.
On pense donc qu'il faudra utiliser des tableaux de variables, pour identifier la position actuelle. pour avancer, plutôt que de revenir. C'est exactement la difficulté de ce retour...