Trace task (constructing a function graph) - page 2

 
sergeev:
One and the same function can be called both from start and from init. This should be fixed.

I can do it on my fingers, but you have to think it through))

like this:

count the number of functions, let it be 4, write #define X 4 in the code header

assume that maximum number of calls on one tick is #define Y 100

we have a matrix of size 4 x 100, initialize matrix = -1

and now, when calling a function at the entry point of the function, add a call of the counter (graph shaper), which should add code (1,2,3 or 4) to the desired position X at the entry into our matrix on the free line - who called

I think that your problem is more like network graphs, I suspect that the matrix for network graphs has long been developed - you need to google

SZY: well, here already is the 2nd page of the topic ;)

 

IgorM, the way you propose to store graph is called "adjacency matrix". It is very uneconomical for sparse graphs (and programmers should be beaten up for "full connected graph" architecture, etc.).

It is much better to use edge list (i.e. we store one-dimensional array of structures consisting of 2 elements - id of calling function and id of called function; the structure can be supplemented with additional fields - call counters, etc.)

p.s. The matapparatus has indeed been developed a long time ago :)

 
lea:

IgorM, the way you propose to store the graph is called a "adjacency matrix".

Thanks, at least I've started to remember something, it's been 15 years since I studied all this stuff, which was never used in real life )))) - But do not forget that "packing data" (memory saving) - will lead to a loss of performance due to increased complexity of the matrix, although I may be wrong
 
MetaDriver:
Proof of impossibility for an idea ?
Logging inputs and outputs from functions is easily done in C++,
there are destructors and such a thing as stack unwinding.
Although... for the same C++ there are libraries that let you build the order of function calls for any
point in code by stack.
.
So... each return means additional calls :-).
 
lea:
A tree is a special case of a graph.

Yes, that's what I meant. Based on the linearity of the MQL code - it will be a tree in its pure form. Since nodes will not point to each other.

IgorM:
have a matrix of dimension 4 x 100, initialize the matrix = -1
and now when calling the function at the entry point of the function we add a call of the counter (graph shaper) which should add a code (1,2,3 or 4) at the required position X to the free row at the entry into our matrix - who called it

Yes, I see it now. But it seems to me this approach is really labour-intensive not so much in code, as in resources and preparation for analysis. For branching you would have to make a three-dimensional matrix.
In general, the option is accepted. But let's leave it to page 4 on the summary for now :)

I think your problem is more like network graphs, I suspect that the mathematical apparatus for network graphs has long been developed - you need to google

The task is neither a know-how, nor a novelty. Just a simple graph of functions. Nothing more.
There's no new math, we just need a simplified version as much as possible.

 
lea:

It's much better to use edge list (i.e. store one-dimensional array of structures consisting of 2 elements - id of calling function and id of called function; the structure can be supplemented with additional fields - call counters, etc.)

Eugene, this is exactly what has already been done.

But the code has stalled. For the third day I can't sleep or drink.... . :)

I can't figure out how to make return from edge (more precisely descendant node) to parent node to go to new edge (new descendant node). But to keep the rule - we use only one tracing function at the beginning of source code function.

 
sergeev:

I can't figure out how to make a return from a rib to a node to go to a new branch.


And all with just a function that has already made a pass forward? That's enough - to make a return without doing anything)) Well, nothing, it's the second page is over, soon Vladimir won't be able to stand it))))
 
alsu:
And all with just one function that has already made a forward pass? You've done enough - make a comeback without doing anything at all))) Well, nothing, it's the second page has already ended, soon Vladimir won't be able to stand it))))

God be with them, with these pages. The task is interesting.

You see, this is how you can.... Rollback to the parent node can be done already in the new called descendant. That is, when you go to the descendant, the system will first go down the tree to a lower level, and then go up to the new called descendant.

But in this option can not make branches with a depth of more than two. Because the system will always go back before going forward. That is, all functions will be drawn at the same level.

So it seems that we will have to use some arrays of variables, to identify the current position. to go further and not to return. That's exactly the complexity of this return...

 

In the trailer "conceptual workpiece", more precisely an example of implementation. on MT 5

In() and out() functions need to be rewritten to make them work with the call list. Now they just print inputs and outputs to the standard thread.

Bad news: I have not saved the topicstarter's dream of one tracing function. Sorry Sergeyev. :)

Good news: Everything works.

User manual.

1. The macro "_in" is inserted at the beginning of each function.

2. All return calls are replaced by "_return"

3. Two defines are written at the beginning of the program

#define _in in(__FUNCTION__);
#define _return out(__FUNCTION__); return


That's all.

Files:
rettest.mq5  2 kb
 
sergeev:

What the hell with these pages. It's an interesting task.

You see, this is how you can.... Rollback to the parent node can be done already in the new called descendant. That is, when you go to the descendant, the system will first go down the tree to a lower level, and then go up to the new called descendant.

But in this variant you can't make branches with more than two depths. Because the system will always go back before going forward. That is, all functions will be drawn at the same level.

So it seems that we will have to use some arrays of variables, to identify the current position. to go further and not to return. That's exactly the difficulty in this return...

And where does such a strange task come from? Is it worth expending effort on dubious research, when you can simply make two functions - input and output - and not bother?
Reason: