You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Dmitry Fedoseev:
Recalculates every time, or does not recalculate
You haven't understood anything. The world has not come to a head with PositionTotal(). I'm just pointing out that it is wrong to do so.
Dmitry Fedoseev:
But instead of bringing a killer experiment
What don't you like about my experiment? Did the compiler over-optimize the result of the first call?
This is exactly what it optimizes: for (int i = 0; i < 1+2 ; i++) {}
or this: const int X = 1 ;for (int i = 0; i < X+2; i++) {}
but this is definitely not: int X = 1 ; for (int i = 0; i < X+1; i++) {} because I am not a telepath and I don't know what and where may happen to this X - it may be modified inside the loop or indirectly, for example, by a link/pointer? It will do the 'X+1' addition for every iteration. Even if you remove '+1', the program will still use the current value of 'X' unless this 'X' is declared as a constant.
And it certainly doesn't cache the result returned by the function, Karl! (anticipating your "but what if for (int index=f();)") - there is only one call here, at index initialization ).
Dmitry Fedoseev:
And the compiler - I meant that it optimizes the code and calls the variable directly, not through a function
Well, yes, of course, the compiler knows exactly the situation on the market and is sure that a function call always returns the same value, so why call this function more than once at all, you have to store the result in OnInit() once, and fine!
And it doesn't care that even within the execution of the cycle itself, in your case with PositionsTotal(), some orders may be already gone - stopped, closed by hands or another EA - and the rest will not be processed, because they all suddenly! got less?
Dmitry Fedoseev:
This is clearly visible with ArraySize() function, you can't tell the difference between calling the function and using a variable. But it's not so with PositionsTotsl(), alas.
How does the size of some array and the number of currently opened positions relate to each other? You're accessing array elements by an index, well, for example, access array[999] with a size of 3 elements. If this array is actually a 'smart' type, a class there for example with operator '[]' where validity check is performed, then fine. But what if it is not? Anyway, this is a classic example of shithcode. Why should we gasify the puddle, just admit it and not bother.
Dmitry Fedoseev:
Recalculates every time, or does not recalculate
You haven't understood anything. The world has not come to a head with PositionTotal(). I'm just pointing out that it is wrong to do so.
Dmitry Fedoseev:
But instead of bringing a killer experiment
What don't you like about my experiment? Did the compiler over-optimize the result of the first call?
This is exactly what it optimizes: for (int i = 0; i = 1+2; i++) {}
or this: const int X = 1 ;for (int i = 0; i = X+2; i++) {}
but this is definitely not: int X = 1 ; for (int i = 0; i = X+1; i++) {} because I am not a telepath and I don't know what and where may happen to this X - it may be modified inside the loop or indirectly, for example, by a link/pointer? It will do the 'X+1' addition for every iteration. Even if you remove '+1', the program will still use the current value of 'X' unless this 'X' is declared as a constant.
And it certainly doesn't cache the result returned by the function, Karl! (anticipating your "what if for (int index=f();)") - there is only one call here, at index initialization ).
Dmitry Fedoseev:
And the compiler - I meant that it optimizes the code and calls the variable directly, not through a function
Well, yes, of course, the compiler knows exactly the situation on the market and is sure that a function call always returns the same value, so why call this function more than once at all, you have to store the result in OnInit() once, and fine!
And it doesn't care that even within the execution of the cycle itself, in your case with PositionsTotal(), some orders may be already gone - stopped, closed by hands or another EA - and the rest will not be processed because they all suddenly! got less?
Dmitry Fedoseev:
This is clearly visible with ArraySize() function; you can't tell the difference between calling the function and using a variable. But it's not so with PositionsTotsl(), alas.
How does the size of some array and the number of currently opened positions relate to each other? You're accessing array elements by an index, well, for example, access array[999] with a size of 3 elements. If this array is actually a 'smart' type, a class there for example with operator '[]' where validity check is performed, then fine. But what if it is not? Anyway, this is a classic example of shithcode. You'd better not try to gasify the situation.
If there is no end in sight at PositionTotal(), you have missed the target at all. Because the ArraySize() function can be called at each loop repetition, and the speed does not change.
I'm not satisfied with your experiment due to its absence.
All your other fantasies are not interesting because they are fantasies (and moreover, they are wild and very far from reality and even false).
You should be in kindergarten.
With the knowledge of what? If it is an algorithm that does not exist in nature, but you have to invent it yourself, and it defines everything.
With the knowledge of how to competently write the right code in the language of interest.
I don't get it, there is no such algorithm that can do this?
In fact, the author has created the topic with this question.
And the cycles and performance of functions were discussed by others. But they are also those who want to know the best way or the right way.
With the knowledge of how to write the right code competently in the language of interest.
I do not understand, there is no algorithm that can do this?
So the author created the topic with this question in mind.
And about loops and performance of functions other people were interested in it. So to speak, more sophisticated in realization of such algorithms) But they, too, are those who want to know how to do it better or how to do it right.
And so you're still about how to calculate positions? Well, then I'm sorry.
Interesting these sophisticated ones, who still want to know... and still don't know. And this is all about counting positions too?
Sorry again, I'm not mistaken, by the phrase "algorithm implementation" do you mean a position counting function? That is, whether you write PositionsTots() in a loop or use a variable - do you call this an algorithm?And so you're still talking about how to count positions? Well, I'm sorry then.
Interesting these sophisticated ones who still want to know... and still don't know. And that's all about counting positions too?
So what are you arguing about if the question is exhausted)? LOL.
There is a task to get position data.
There is a language function to get the number of open positions, which is used in the loop.
There is a question how to use it correctly in the loop: in the first parameter of the for loop or by the second - where the condition is checked.
It's strange that you don't understand what you want)))
You write that it is costly because the number is not constant. But why, you can't explain.
Can you explain why it is costly?
I personally think the developers made sure that this function would not recalculate open positions every tick, and would only do it when opening and closing a position.
Do you think the developers have not thought of this?
How can you be so sure that the function is costly and recalculates, and does not just take the value from the terminal's memory?
So far, instead of a substantive answer, I have read idle chatter.
So what are you arguing about if the issue is over)? LOL.
That's the humour of the situation - for the second twenty-four hours on page four a symposium on how to count positions. Very interesting.
If PositionTotal() is not the only thing that matters, then you've missed the point. Because the ArraySize() function can be called at each loop repetition, and the speed does not change.
I'm not satisfied with your experiment due to its absence.
All your other fantasies are not interesting, because they are fantasies (and moreover, they are wild and very far from reality, and even false).
ArraySize(), if an array isn't dynamic or of a class type, it's already a constant when declaring the array itself. But it doesn't mean anything yet, because ArraySize(array) and sizeof(array) are two big differences. The first is called but you don't see it; the second is calculated at the compilation stage.
So tell your alternative point of view somewhere else.
-----------------
Why am I trying to explain myself? A person doesn't want to see and think. Very well, let him generate code which operation depends on moon phase, mean Mars meridian time and left hind heel itch. The only pity is that many people, especially novices, don't even think twice about copying *new* code into their projects and then puzzle over what is wrong.
ArraySize(), if the array is not dynamic and not of class type, it is already a constant when declaring the array itself. But this also doesn't mean anything, because ArraySize(array) and sizeof(array) are two big differences. The first is called but you don't see it; the second is calculated at the compilation stage.
So tell your alternative point of view somewhere else.
-----------------
Why am I trying to explain myself? A person doesn't want to see and think. Very well, let him generate code which operation depends on moon phase, mean Mars meridian time and left hind heel itch. The only pity is that many people, especially novices, don't even think twice about copying *new* code into their projects and then puzzle over what is wrong.
That's a killer argument! No words... Why should you apply ArraySize() to a non-dynamic array? I cannot imagine how one could think it up. And what does sizeof() have to do with it? Everything OK there?
And this is not my point of view, but one that has long been verified by forum participants. But I will not search for this thread.
But I can tell you that it has nothing to do with caching at all.
For me, I think it's good that a person tries to understand and digs deeper...
By not paying attention to small things, the coder then gets into the habit of writing code in the wrong way. And then combing the code means double work and often not only for the author but for those who are still lucky to work with the code.
Why bother writing code when you can do it properly and write it well and understand the details?)
Your advice is... well... IMHO
Your advice is good for an experienced programmer (highly confident) who can then comb through it, because he or she knows where and what must be combed.
Fedoseyev is right. You don't have to, and it will take some time to comb the code as you would like. But you understand with time that you'd better write something new. So every new code will be combed at first.
Interesting realities of the forum. When someone asks about something, no one will write a line of code. But as soon as they do, they come, line up and start tapping - ah, ah, ah, what a wrong code. And what is interesting, it usually concerns the code as simple as three kopecks. Every space is under scrutiny. As for something more complicated, there is silence, deaf as a tank.