New MetaTrader 4 Client Terminal 387 and MetaTrader 4 Data Center build 387 - page 15

 
joo:

Everyone is entitled to a personal opinion, but no one has the right to insult others.

In this case, it's all perfectly transparent - two forum members expressed their very negative views on nen's post, which was followed by a ban, and Renat clearly explained what the ban was for.

+100
 
joo:

.... The ban followed, and Renat clearly explained the reason for the ban.

I only asked you to do two things:

1) to inform the visitor to the profile of a forum member that this same forum member is banned.

2) when the ban is issued - to specify the reason (not after the intelligible explanation, but at the time of the announcement of the ban).

This is just technical stuff, which has nothing to do with morality, or education, or anything else.

I still dare to suggest the correct way to ban a user: a user should not be banned from the forum, but only the creation of new threads and posts. so that the banned at least could ask a question (in private) and not litter the user list with new nicknames.

It's purely a technical/technological request/suggestion to improve the forum engine.

 
f.t.:

I only asked you to do two things:

1) to inform the visitor to the profile of a forum member that this same forum member is banned.

2) when the ban is issued - to specify the reason (not after the intelligible explanation, but at the time of the announcement of the ban).

This is just technical stuff, which has nothing to do with morality, or education, or anything else.

I'll also dare to suggest the correct way to ban a user: a user should not be banned from the forum, but only the creation of new threads and posts. that banned at least could ask a question (in private) and did not litter the user list of new nicknames.

this is purely a technical/technological request/proposal to improve the forum engine.

I personally have nothing against what you said, on the contrary, I support it. It's just that your example with nen was unfortunate and I posted with a hint of that.
 
ANG3110:

OK, I'll have a look at the article you're referring to.

About the under-loaded data... Now, because of the passage of time, I can't quote the logs. But it looked something like this.

On American broker ATC, EA was left on and the terminal was closed. The next day the terminal was opened and after opening and automatic login there was a pause with no quotes. The Expert Advisor sent an additional request to open a position and the history started to be swapped and the position was opened according to the previous day's calculations in the area where it should have been closed but it was just opened and instantly lost against the market that was moving in the opposite direction. The position ended up being closed with a deep loss, I do not remember how much it was lost but a lot.

Another case. I left an Expert Advisor with a channel calculation in its algorithm, something similar to Bollinger, but requiring many bars because it had an adaptation algorithm. I did not see the moment when the trade started, but I saw it about 20 minutes later. It turned out that deviations from the adapted average were not considered and the channel broke in the line, as if lying on the average. My Expert Advisor was opening and closing one position after another and it lost about $4,500 in 20 minutes by 0.2-0.3 lots. 4,500$ in a totally winning market. This could happen if there was either very little data or something was missing for the design I cited above.

Now I always switch off EAs after trading. Now I always disable Expert Advisors after the first time I open the terminal again and wait for the data to be pumped and only then turn them on.

From my point of view

an EA requires data to be available (usually any data)

For all errors are divided into errors in the code and errors in the data!

The problem is solved by analysing the availability of the data. The problem is solved by analyzing the availability of the required data

and their correctness before using them!


For example: Before dividing, it is elementary to check if we are trying to divide by zero.

this will be the correct tone in almost any situation, even if you are sure ... that a variable ... cannot be = 0

checking will give 100% certainty that the program will not crash when dividing! SO CHECK THE DATA!




to avoid this kind of thing!

the Expert Advisor should know exactly how many bars it needs!

further a simple but effective algorithm

you should start from the currently working candle on the necessary timeframe or timeframes

to run to the correct depth! s and see if there are any missed bars - it's not very difficult

i will not give the code ... there are those here who can easily write such a code!


Next, the Expert Advisor just does not rip or close, it BREAKS!!! that there is no FULL HISTORY!

you !!! take this into account - take steps to fill in the missing bars!

and only after that you allow it to trade!

--

your problem is that your algorithm has no such control!

add! because it's easier than losing $4,500 ...

--

For those who can't write such a code, they will write it here for $100-200

it's less than $4,500!

 
YuraZ:

from the current working candlestick on the desired timeframe or timeframes

run to the right depth! s and see if there are any missed bars - it's not too difficult

Thanks Yura for the tip.

But what should I do, if I have just opened the terminal and zero bar is still old, e.g. from the previous day. Of course, we can run to a certain depth from it counting the missed bars, but it will be an error. How does the EA know if this is the last bar or not? I said earlier that in principle one can compare TimeLocal() and TimeCurrent() taking into account the difference in time and adding a small delta, because sometimes there is no quote for 3-5 minutes, especially at CAD pairs, and probably it can be considered an error. Maybe, it is enough to do it during initing and fixing of missed bars afterwards, for example, when communication is interrupted for several minutes, and probably it is not necessary to re-calculate at every bar because it would take too much time to count. The Expert Advisor I wrote about losses requires up to 20 thousand bars for statistical initial adaptation. For such a number it would be distressing to run cycles on each bar and probably is not necessary. Of course, it is not the best way and depends on the computer clock in addition. Maybe you can think of something better? However, as I've watched lately, if IsConected() function triggered, zero bar usually appears almost immediately.

 
ANG3110:

Thanks, Yura, for the tip.

But what should I do, if the terminal is just opened and the zero bar is still old - let's say of the previous day. Of course we can run to a certain depth from it counting the missed bars, but it will be an error. How does the EA know if this is the last bar or not? I said earlier that in principle one can compare TimeLocal() and TimeCurrent() taking into account the difference in time and adding a small delta, because sometimes there is no quote for 3-5 minutes, especially at CAD pairs, and probably it can be considered an error. Maybe, it is enough to do it during initing and fixing of missed bars afterwards, for example, when communication is interrupted for several minutes, and probably it is not necessary to re-calculate at every bar because it would take too much time to re-calculate. The Expert Advisor I wrote about losses requires up to 20 thousand bars for statistical initial adaptation. For such a number it would be distressing to run cycles on each bar and probably is not necessary. Of course, it is not the best way and depends on the computer clock in addition. Maybe you can think of something better? However, as I was watching lately, if the IsConected() function triggered, the zero bar usually appears almost immediately.

Well, everything seems simple to me... The int start() procedure is called only at a new tick, and it is 100% means that function TimeCurrent() (returns the last known server time (time of the last quote arrival)) will already be actual regardless of availability of bars...

I think everything is clear after that...

 
Renat:

Unfortunately, you have not specified any initial data, test parameters or logs.

Furthermore, you are referring to libraries (DLL), which not only require a lot of installations, but also do not work due to lack of additional libraries (this is to the author of the libraries, who forgot about additional DLL files).

Contact the author of these libraries for information.


If you followed the link provided by me, you would see that only one input parameter has a value and it is set as described: StopLoss=100...1 000 step 10; x=1...1 000 000 step 1. Besides, I told you that the previous build did not generate this error, so the error is yours. Everything actually works. It only gives out this strange message. So, it may be only this message for me and it may fail to work for someone else because of the consequences of this error.
 
ANG3110:

Thanks, Yura, for the tip.

But what should I do, if the terminal is just opened and the zero bar is still old - let's say of the previous day. Of course we can run to a certain depth from it counting the missed bars, but it will be an error. How does the EA know if this is the last bar or not? I said earlier that in principle one can compare TimeLocal() and TimeCurrent() taking into account the difference in time and adding a small delta, because sometimes there is no quote for 3-5 minutes, especially at CAD pairs, and probably it can be considered an error. Maybe, it is enough to do it during initing and fixing of missed bars afterwards, for example, when communication is interrupted for several minutes, and probably it is not necessary to re-calculate at every bar because it would take too much time to re-calculate. The Expert Advisor I wrote about losses requires up to 20 thousand bars for statistical initial adaptation. For such a number it would be distressing to run cycles on each bar and probably is not necessary. Of course, it is not the best way and depends on the computer clock in addition. Maybe you can think of something better? Although, as I was watching lately, if the IsConected() function triggered, the zero bar usually appears almost immediately.

Hi!


this can be checked logically too!

First, you get some ticks and time the TimeCurrent() and if it is far from the bars, you load it - but you also need to take into account the weekend.

on monday you need to know the start time at your broker, and on friday the finish time ( at that, on small ff have a small error of a few bars

( start time on Monday and finish time on Friday may be calculated automatically by the averaging method for a larger period )

example of logic

// простой пример контроля истори, просто логика 
 
int ФЛАГпроверкиИСТОРИ =0; // 0-история не проверена или не загружена

void init()
{
    ФЛАГпроверкиИСТОРИ   =0; // ставим флаг
}


void start()
{
     // читаем историю на предмет пропущеных баров
    if ( ФЛАГпроверкиИСТОРИ   == 0)
    {
// проверяем а вся ли нужна история есть и если нет то она загружается
      // загружаем
       если загружена ФЛАГпроверкиИСТОРИ=1;
       return;
    }
}


 
Akkarin:

If you followed the link provided by me, you would see that only one input parameter has value and was set, as it is told in the description: StopLoss=100..1 000 step 10; x=1..1 000 000 step 1. Besides, I said that the previous build did not generate this error, so the error is yours. Everything actually works. It only gives out this strange message. So it may be just this message for me, while someone else can fail to work at all because of the consequences of this error.


I diligently sorted everything out, read it all, understood the logic, but came up against exactly what he said - not enough third-party dll library, which the author of the library set has not laid out (although even made the installer).

Apparently, a trivial forgetfulness. But I can't scour the internet looking for some dll files.