Anyone who wanted to see charts without missing bars - here =) - page 2

New comment
 
komposter:

Because the indicators are calculated a certain number of bars backwards. If there are gaps - it is clear that the same MA may at different points in time be calculated for different periods of TIME backwards. I.e. when calculating MA(9) it is implied that MA is calculated for the last 9 time periods. And if there are omissions, we will get (in fact) then MA(10), then MA(20).


Why? On ALL* charts too?


I specifically clarified: on the charts generated by the AllMinutes expert, is it wrong too?

Right as far as indicators on invented data can be right :) More correct than on skip data anyway, but still :(

The question with the Causes of skipping is still open.


Alternatively, a constant check for IsConnected().
Also, if the bars were missing due to loss of connection, when it resumes, they should be pumped up.
However, I haven't tested such a situation and don't know how the "hole filler" would behave.
Patch. But again, not a solution - what to do with a hung server, for example (don't tell me it's not realistic!)? In fact, there's a lot of possibilities - client glitches, protocol errors, network settings, etc. In this case IsConnected() will report that everything is OK. However, the quotes will be delayed. Or get lost altogether. The only way to solve the problem, which I can see, is to confirm that the price is unchanged on the server side. If there is no such confirmation, it means that the problem lies elsewhere. I don't insist that there shouldn't be such problems, but I WANT TO KNOW WHEN they occur.
 
max_cpr писал (а):

The only way I can see to resolve the issue is for the server to confirm the REAL price.


And if the confirmation of unchanging is lost just like a ping might be lost now?
The server availability survey, as far as I understand it, happens all the time. And there's no difference between checking connection status and requesting unchanged price.
Imho, of course.
 
komposter:
max_cpr:

The only way I can see to solve the issue is for the server to confirm that the price is INCREDIBLE.


And if the confirmation of immutability is lost just like a ping might be lost now?
The server availability survey, as far as I understand it, happens all the time. And there's no difference between a normal connection status check and a request for unchanged price.
Imho, of course.
If the price confirmation is lost (in the form of a message about current price) - it is clear that there are technical problems. And the reason for the loss is not even that interesting - it is only important to handle this situation correctly. Requests to the server, in terms of confirmation of price relevance, generally do not make sense - although it would be nice to receive confirmation of the price on request (for example, immediately before placing an order). The server's accessibility does not guarantee the last known value of the price. As in the general case, pinging a server does not guarantee that it will be able to communicate with a remote server. I want to emphasize the difference - confirmation of server operability should be seen (oddly enough :) in HIS WORK, i.e. quotes delivery. And absence of quotes from the server should be interpreted as erroneous situation and accordingly it should be dealt with. Which is impossible to do now without a crooked patch...
 
We don't seem to hear each other. Or don't understand )
 
Will this fill-in have no effect on the generation of tick data?
 
nikkei:
Will this fill-in have no effect on the generation of tick data?
If generated from standard charts (standard MT tools), it will not.
 
I tried renaming the file name of the completed history and replacing it with incomplete one - it doesn't want to generate ticks in the tester at all. The file format must be different there, so it is probably not suitable for backtest, only in realtime.
 
No, it is possible to test on "stitched" charts too.
Only for this purpose, besides changing file name, you should change symbol name in file header.

For this purpose, in AllMinutes Expert Advisor you should leave only _Symbol [curChart ] (symbol name) wherever the "ALL" line connects to the _Symbol[curChart] line.
Be careful, sometimes they are joined by StringConcatenate() function. If this function has only 2 arguments, you should not use it at all. For example, instead of
StringConcatenate( "ALL", _Symbol[curChart] )
it should be
_Symbol[curChart]

But if there are more arguments, the function should be kept, simply by removing "ALL" from it. For example, instead of
StringConcatenate( "ALL", _Symbol[curChart], _Period[curChart], ".hst" );
there should be
StringConcatenate( _Symbol[curChart], _Period[curChart], ".hst" );


In addition, the chart of the corresponding symbol and period should be closed. Otherwise MT itself will download the "correct" (on patched) quotes.
And in general, to me, such testing makes no sense =)
It is better to test on a standard tool, and read the indicators on ALL charts. For this purpose, it is enough to generate the necessary charts, open them in offline mode, and at calculation of indicators indicate StringConcatenate("ALL", Symbol() ) as the first argument.

Good luck ;)
 

[Quote]I tried renaming file name of completed history and replacing it with incomplete one - it doesn't want to generate ticks in the tester at all. The file format must be different there, so I guess it's not suitable for backtest, only for realtime. [/Quote]
I just imported quotes from ALL... that's all... :)
Tell me, komposter, is it possible to load real tick quotes into the tester in this way? I thought the guys from MetaQuotes said it's possible...

 
But here's the interesting thing... I made a simple EA with a line like this:
WriteLineInFile(esFileNameOfReport,GetCurRusTime()+"Минута: "+TimeMinute(CurTime()));
I converted all other timeframes from patched minutes, deleted all .fxt. I have tested "All ticks" model. I tick "recalculate". On M1 timeframe all ok, one minute to one minute... But on M15, for example, it's skipping of minutes again... Question: Where does this creep (tester) get the minutes from? I have a suspicion that it simply ignores the minutes with equal OHLC... Question: what's the point of catching the holes then?
123456789...12
New comment
Reason: