Is the tester working correctly ? - page 5

New comment
 
Integer:
Yeah... I jumped the gun on that one.... Turns out there are bars that have an opening price equal to the closing price of the previous one. I don't know what system MT uses to draw bars. I think only the developers will be able to explain it. I would like very much to understand it.

If there has been a period of off-quota, then at the appearance of quotes the broker may give a tick with the same price. But this is only a guess.

If only our reltime data is used and there are no intersession gaps or server restarts, then Close of one bar cannot be equal to Open of the next one. If imported data is used, it can be.
 
Renat:
Integer:
Yeah... I was in a hurry.... Turns out there are bars that have an opening price equal to the closing price of the previous one. I'm not sure of the correctness of the equation. I think only the developers will be able to explain it. I would like very much to understand it.

If there has been a period of off-quota, then at the appearance of quotes the broker may give a tick with the same price. But this is only a guess.

If only our reltime data is used and there are no intersession gaps or server restarts, then Close of one bar cannot be equal to Open of the next one. If imported data is used, it can happen.
This happens in any data of minute timeframe - see for yourself and in those quotes, which I have downloaded from Alpari, I think, also.



Here is an example: real time quotes, your demoserver. Look at the highlighted bar and the two bars above. On the highlighted bar, the tick volume value should be 0. Since price change to this level is accounted for by the tick volume of the previous bar.
Two bars higher than 1 is correct.

And this is not an isolated case. Look through the history. I think it is not about the requotes.

That is why the question appeared.

Good luck. Sincerely, Vladislav.

ZS Sorry - this example is not correct - I looked in the wrong place. I will now look for it elsewhere.
ZZZY ran your script data - eyes were afraid to make a mistake again - in those that I received the realtime from your server is really not. So I remove the question.

Good luck. Regards, Vladislav.
 
VladislavVG:
Renat:
Integer:
Yeah... I jumped the gun on this one.... Turns out there are bars that have an opening price equal to the closing price of the previous one. I don't know what system MT uses to draw bars. I think only the developers will be able to explain it.

If there has been a period of off-quota, then at the appearance of quotes the broker may give a tick with the same price. But this is only a guess.

If only our rltime data is used and there are no inter-session gaps or server restarts, then Close of one bar cannot be equal to Open of the next. If imported data is used, it can be.
This happens in any minute timeframe data, you can see for yourself and in those quotes that I have downloaded from Alpari too.

Here's an example: real time quotes, your demoserver. Look at the highlighted bar and the two bars above. On the highlighted bar the tick volume value should be 0. Since price change to this level is accounted for by the tick volume of the previous bar.
Two bars higher than 1 is correct.

And this is not an isolated case - it is always there. So, to be more correct, I have not found a single bar that would contain zero in the selected case. Look at the history. I think it is not about requotes.

That's why the question arose.

Good luck. Sincerely, Vladislav.


And what did you want to show with this example? Bar dodge from one quote (OHLC = one price)?
So it is an absolutely normal situation. There are no errors or discrepancies.
 
Renat:
VladislavVG:
Renat:
Integer:
Yeah... I jumped the gun on this one.... Turns out there are bars that have an opening price equal to the closing price of the previous one. I don't know what system MT uses to draw bars. I think only the developers will be able to explain it.

If there has been a period of off-quota, then at the appearance of quotes the broker may give a tick with the same price. But this is only a guess.

If only our rltime data is used and there are no inter-session gaps or server restarts, then Close of one bar cannot be equal to Open of the next. If imported data is used, it can be.
If you do not have such a good idea, you can use the right hand to fix the problem.

Here is an example: real time quotes on your demoserver. Look at the highlighted bar and the two bars above. On the highlighted bar the tick volume value should be 0. Since price change to this level is accounted for by the tick volume of the previous bar.
Two bars higher than 1 is correct.

And this is not an isolated case - it is always there. So, to be more correct, I have not found a single bar that would contain zero in the selected case. Look at the history. I think it is not about requotes.

That's why the question arose.

Good luck. Sincerely, Vladislav.


And what did you want to show with this example? Bar dodge from one quote (OHLC = one price)?
So this is an absolutely normal situation. There are no errors or discrepancies.
Yes, I have already seen and corrected the previous post.

Good luck. Regards, Vladislav.
 
VladislavVG:

Sorry - this example is wrong - I looked in the wrong place. I'll look elsewhere.
ZZZY ran your script data - eyes were afraid to make a mistake again - in those that I received the realtime from your server really no such thing. So I remove the question.


Yes, I also wrote a script to check the condition if(Close[previous]==Open[current]) and found this only on imported data. There is no such thing on our reltime data.
 
Renat:
VladislavVG:

Sorry - this example is wrong - I looked in the wrong place. I'll look elsewhere.
ZZZY ran the script your data - eyes were afraid to make a mistake again - in those that I received the realtime from your server really no such thing. So the question removed.


Yes, I also wrote a script to check condition if(Close[previous]==Open[current]) and found it only on imported data. There is no such thing on our reltime data.
Do I understand correctly that the tester should badly distort the tests in such a situation? Perhaps we should add such a check to the standard script ? It is clear that it is better to use verified data for tests. But many traders test systems on their broker's data - misunderstandings are possible.

Good luck. Regards, Vladislav.
 
VladislavVG:

Yes, I also wrote a script to check the condition if(Close[previous]==Open[current]) and found this only on imported data. There is no such thing on our relay data.
Do I understand correctly that the tester has to distort the tests a lot in such a situation? Perhaps we should add such a check to the standard script ? It is clear that it is better to use verified data for tests. But many traders test systems on their broker's data - misunderstandings are possible.

Good luck. Sincerely, Vladislav.
Absolutely wrong. There is no distortion, except for erroneous thinking about one pip in the traders' heads.

Understand that you should never rely on ticks in testing. On the contrary, you should ignore the noise movements within the half-spread-spread. Almost every trader goes through a trivial pips hoping for an extra pip. And most traders justify themselves with "no, I'm not a pip trader, I want accurate execution" :)

People deceive themselves hoping for absolutely accurate and guaranteed execution, and then are surprised that in reality they get requotes, and it is impossible to make a deal in a fast market. Not only that, but many do not deal with requotes and other trade server responses at all.
 
Renat:
VladislavVG:

Yes, I also wrote a script to check the condition if(Close[previous]==Open[current]) and found this only on imported data. There is no such thing on our relay data.
Do I understand correctly that the tester has to distort the tests severely in this situation? Perhaps we should add such a check to the standard script? It is clear that it's better to use verified data for tests. But many traders test systems on their broker's data - misunderstandings are possible.

Good luck. Regards, Vladislav.
Absolutely wrong. There is no distortion other than mistaken thoughts about a single pip in traders' heads.

Understand that you should never rely on ticks in testing. On the contrary, you should ignore the noise movements within the half-spread-spread. Almost every trader goes through a trivial pips hoping for an extra pip. And most traders justify themselves with "no, I'm not a pip trader, I want accurate execution" :)

People deceive themselves hoping for absolutely accurate and guaranteed execution, and then are surprised that in reality they get requotes, and it is impossible to make a deal in a fast market. Not only that, but many do not deal with requotes and other trade server responses at all.
I've never really hoped for accurate execution. And concerning the ticks I understand them very well. In general all my stops are outside statistically significant reversal zones and certainly not closer than 2.5 ATR behind the previous bar extremum :). That is, there is not even a hint of "scalping" algorithms. Regarding the half-spread, I would even say that a value expressed in APR is a more accurate estimate (verified by practice).

I wanted to know how much such "interference" (let's call it that) can affect the quality of the tester itself. I wrote above that I don't consider the strategy itself.
From your reply I conclude that they cannot. Good for you.

Good luck. Regards, Vladislav.
 
Renat писал (а):

If only our relay data is used and there are no inter-session gaps or server restarts, then the Close of one bar cannot be equal to the Open of the next. If imported data is used, it can be.

I don't have imported data, but data uploaded to MT "legally" from the DC.
 
Integer:
Renat wrote:

If only our relay data is used and there are no intersession gaps or server restarts, then Close of one bar cannot be equal to Open of the next. If imported data is used, this can happen.

I don't have imported data, but uploaded to MT "legally" from DC.
So they have been imported into the trade server - this is common for historical data from earlier periods.
1234567
New comment
Reason: