Mt4 End of support. - page 39

[Реter Konow]

George Merts:

It is arguable that this is an advantage.

Accidentally someone will change the flag - and this will affect the behaviour of the TC.

Well, there's no way to be immune to accidents. The human factor is unstoppable.)

[Nikolai Semko]

Реter Konow:

My initial task: To show effective solutions without using OOP.

The essence of my solution: - generating a global array of event flags of new bars of all symbols and timeframes once per minute.

Advantages:

1. Automatic filling of the array and automatic clearing.

2. no system load.

3. Direct access to the array from any function and saving the event flag before the array is cleared.

Shit, woke up finally....

You understand that a bar of any symbol can come at any instant and the task is as if to tell the system at the same instant that a new bar has come. How do you envisage that when you poll the system once a minute?

[Georgiy Merts]

Реter Konow:
Well, we cannot be secured against accidents. The human factor is unstoppable)).

There you go. Therefore, I believe that code should be written in such a way that it limits possible human errors as much as possible. Precisely because the human factor is an irreducible one. As recently as yesterday I've found a mistake in my code, because of which the statistics on Expert Advisor was collected from the beginning of history, and not from the specified date (date of EA creation). I simply forgot to initialize the variable and it remained zero.

So, now I've redesigned the analyzer in such a way that it would be necessary to specify the date, from which the analysis would be done, and the Expert Advisor's parts factory would return only the date of creation and no others.

Now it's impossible to analyse the trading history before the date of creation of the Expert Advisor. Even if the former version made trades - they will not be included into statistics now.

[Georgiy Merts]

Nikolai Semko:
Shit, finally woke up....

You realise that the bar of any symbol can come at any instant and the task is as much to tell the system at the same instant that a new bar has arrived. How do you envisage that when you poll the system once a minute?

Why "at this very moment" ???

You, my friends, simply have different approaches to making trades. If we are working on the M1 timeframe - we should get the information that a new bar has arrived - not "at the same instant", but at the arrival of a new minute. If we are working on the S1 timeframe (hello, Volchansky) - we should get this information at the arrival of a new second. If we are working on every tick - the information should come with the arrival of a new tick.

And there's the "work by event" option - but then we shouldn't have the IsNewBar() function, but the OnNewBar() function, which is actually a "subset" of the OnTick() function

[Реter Konow]

Nikolai Semko:
Shit, finally woke up....

You realise that a bar of any symbol can arrive at any moment and the task is as much to tell the system at that very moment that a new bar has arrived. How do you imagine this will happen when you poll the system once a minute?

The iBars() function will always return the current number of bars. If it has changed since the last call, it will commit a new bar event to the array, if it hasn't changed, it won't commit.

[Реter Konow]

Nikolai Semko:
Shit, woke up finally....

You do realise that any symbol bar can come at any instant and the task is as much to tell the system at the same instant that a new bar has come in. How do you envisage that when you poll the system once a minute?

I see. So the bar may not arrive when iBars are requested, but may arrive a moment after the request. Then it will be missed for the system. That's the point.

Then what, to be continuously accessed? - Clearly not the best solution.

[Alexey Viktorov]

Реter Konow:

I see. So the bar may not come at the moment of polling, but will come a moment after polling. Then it will be missed for the system. That's the point.

Peter, I suggest another topic for discussion, for the second time. No need to write anything, just theory.

Forum on trading, automated trading systems and testing trading strategies

Mt4 End Support.

Alexey Viktorov, 2017.09.11 13:08

I think I've found a primitive example of the usability of OOP. Here's a function to fill an array with a specified value. There are eight varieties depending on array type.

Imagine you need to write a function that needs to pass one set of parameters, then another, then a third... Using algorithmic approach you'll get N different function's names. It would seem that there is nothing wrong, you can write 8 such functions as ArrayInitializeInt()ArrayInitializeDouble() and so on. But it's so nice not to have to think about the type of an array, just use one function in any case, and it's safe to mix up which array you put there...

[Реter Konow]

Alexey Viktorov:

Peter, I suggest another topic for discussion, for the second time. No need to write anything, just theory.

Please wait a little while. We will fully understand this topic and I will carefully read the second one.

[Alexey Viktorov]

Реter Konow:
Just a moment please. We'll fully understand this topic and I'll take a close look at the second one.

As you remember the topic of the new bar was brought up to find out the pros of OOP, but in no way programming options, much less your abilities. But the remarks to your code and algorithm in general turned the discussion in the wrong direction. So I think there is no need to continue it.

[Реter Konow]

Alexey Viktorov:

As you remember, the topic of the new bar was brought up to find out the pros of OOP, but not programming options, much less your abilities. But remarks to your code and algorithm in general turned the discussion in the wrong direction. So I think there is no need to continue it.

That is, you want me to continue trashing the advantages of OOP, and everyone kept trolling me?) But you're basically right. The discussion has gone in the wrong direction.